[Qt-creator] How to put custom build steps into Git?

[Murphy, Sean]

For our project, we've got two build customizations that we do, that we'd like to be able to put into source control, so that all developers automatically get them. But it appears that adding those steps via Qt Creator causes that information to get stored locally in the .pro.user file, which appears to have user-specific file paths in it, thereby making it a file that I don't think should ever get checked into source control?

So what's the right way to handle this sort of stuff?

Sean

PS - my question is really more intended in the general sense but the two specific things we're trying to put in there are:
- under the Build Settings->Build Steps->Make->Make arguments we want to add the "-j" flag to speed up compilation
- I've written a custom application that runs as a pre-build step. This application updates a header file with the current Git hash information so that that info get compiled into the application in the About dialog. This way, when users report an issue, I know which commit to start from. This application is located in a path that has a fixed RELATIVE path to the .pro file for the main project, but we need it automatically included as part of the build process when a user clones into this repository and opens the .pro file that the pre-build step is known and executed.

PPS - if there's a cleaner way to grab the Git hash compiled into the application, I'm all ears.


This message has been scanned for malware by Forcepoint. www.forcepoint.com

[Tobias Hunger]

Hi Sean,

Post by Murphy, Sean
For our project, we've got two build customizations that we do, that we'd
like to be able to put into source control, so that all developers
automatically get them. But it appears that adding those steps via Qt
Creator causes that information to get stored locally in the .pro.user
file, which appears to have user-specific file paths in it, thereby making
it a file that I don't think should ever get checked into source control?

Yes, that is correct.

My idea still is to make creator look in the source directory for a
"project setup wizard" and run that when a project is first opened. That
would be the most powerful solution to your problem I can think of and
would allow fully automatic setup as well as a UI to get I put from the
users.

Alas that has been on my agenda for a long time now.

So what's the right way to handle this sort of stuff?


Ideally everything extra should be part of the build system itself so that
the "normal" sequence of commands is enough.

That makes things simple for the IDE but also for developers that chose not
to use Creator.

PS - my question is really more intended in the general sense but the two

Post by Murphy, Sean
- under the Build Settings->Build Steps->Make->Make arguments we want to
add the "-j" flag to speed up compilation

I make sure MAKEFLAGS is set to "-j8" in the project environment.

I do that via the global system environment that is set before creator is
started, but you could also set this up as part of the kits you use inside
creator.

- I've written a custom application that runs as a pre-build step. This

Post by Murphy, Sean
application updates a header file with the current Git hash information so
that that info get compiled into the application in the About dialog. This
way, when users report an issue, I know which commit to start from. This
application is located in a path that has a fixed RELATIVE path to the .pro
file for the main project, but we need it automatically included as part of
the build process when a user clones into this repository and opens the
.pro file that the pre-build step is known and executed.

That is something that should be done by the build system IMHO. Have that
take a app_version.h.in and use your program to generate app_version.h from
that. Now add a bit hook or something that touches the .in file on git
changes.

I have not tested that, but that is how I would try to address that problem.

[Murphy, Sean]

Post by Tobias Hunger
That is something that should be done by the build system IMHO

Can you expand on this part? By build system, I assume you mean qmake?
If that's what you meant, I'm all for doing it that way as well, how would I
go about adding what I'm looking for into the .pro file?

Basically, in our current setup, we're all using qmake as the build system,
so if there's a solution that works via qmake variables, I'm totally fine with
that too, I just haven't found them yet if they exist. If it matters, we're
currently targeting Windows (using mingw compiler) and Mac desktops,
but have plans for Android and iOS down the road, so I'd like to have this
be something that is set up once, and then each developer gets it for free
when they clone the Git repo.

As it stands right now, each developer has to manually set these up. Hell,
I even have to manually set it up if I clone my repository on my own
machine. I usually have our release branch checked out in one directory,
and then I clone from there into other directories to create feature
branches. So on that cloned repo, I've temporarily lost those build settings
until I manually re-add them to that cloned directory's .pro.user file,
either by manually copying the previous .pro.user file over, or by using
the Projects pane in Qt Creator to add the steps back in.

I'm also totally open to being told my approach is just completely wrong,
as long as someone has a better approach!

Thanks,
Sean



This message has been scanned for malware by Forcepoint. www.forcepoint.com

[Orgad Shaneh]

Post by Murphy, Sean

Post by Tobias Hunger
That is something that should be done by the build system IMHO

Can you expand on this part? By build system, I assume you mean qmake?
If that's what you meant, I'm all for doing it that way as well, how would I
go about adding what I'm looking for into the .pro file?

You can do it by:
git_ver.commands = your-app-that-generates-the-version-header
git_ver.target = your-header.h
QMAKE_EXTRA_TARGETS += git_ver
PRE_TARGETDEPS = $$git_ver.target # This should not be needed if cpp files
use this header.

- Orgad

[Murphy, Sean]

This looks really promising, I’ll play around with this and see where I get.

Sean Murphy
Sr. Project Engineer
Walbro LLC
4144 Doerr Rd
Cass City, MI 48726
ph. 989 872 7274
cell 734 223 8975
fax. [phone]
***@walbro.com<mailto:***@walbro.com>

Confidentiality Notice: The materials contained within this e-mail transmission (including all attachments) are private and confidential and the property of the sender. The information contained in the materials is privileged and intended only for the named addressee(s). If you are not the intended addressee, be advised that any unauthorized disclosure, copying, distribution or the taking of any action in reliance on the contents of this material is strictly prohibited. If you have received this e-mail transmission in error, please immediately notify the sender by telephone at 989-872-7274 or send an e-mail to ***@walbro.com<mailto:***@walbro.com> and thereafter destroy the e-mail you received and all copies thereof.

From: Orgad Shaneh <***@gmail.com>
Sent: Friday, July 06, 2018 11:00 AM
To: Murphy, Sean <***@walbro.com>
Cc: qt-***@qt-project.org
Subject: Re: [Qt-creator] How to put custom build steps into Git?

Post by Tobias Hunger
That is something that should be done by the build system IMHO

Can you expand on this part? By build system, I assume you mean qmake?
If that's what you meant, I'm all for doing it that way as well, how would I
go about adding what I'm looking for into the .pro file?

You can do it by:
git_ver.commands = your-app-that-generates-the-version-header
git_ver.target = your-header.h
QMAKE_EXTRA_TARGETS += git_ver
PRE_TARGETDEPS = $$git_ver.target # This should not be needed if cpp files use this header.

- Orgad


Click here<https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==> to report this email as spam.


This message has been scanned for malware by Forcepoint. www.forcepoint.com

[Andy]

For my git info, I am using what feels like a hacky way to avoid having to
add pre-build steps on every single project configuration. Might help?

In my .pro:

# Get our build info from git

OTHER_FILES += "$$PWD/gen_header.sh"


!build_pass {

UNUSED_RESULT = $$system(bash "$$PWD/gen_header.sh")

}


And then the contents of gen_header.sh:

#!/bin/bash


(

echo '// Generated by gen_header.sh - do not edit'

echo

echo '#define GIT_VERSION_LONG "'`git describe --long`'"'

echo '#define GIT_VERSION_HASH "'`git log --pretty=format:'%h' -n 1`'"'

echo

echo '#define GIT_BUILD_DATE_LONG "'`git log -n 1 --format=%ai`'"'

echo '#define GIT_BUILD_DATE_SHORT "'`git log -n 1 --format=%ad
--date=short`'"'

) > gitVersion.h


On Windows I have cygwin installed, so bash may be found. Maybe this trades
one type of config for another, but I already use cygwin for many things so
I have it installed on all my Windows build machines.

Another limitation is that it executes every build, but I'm willing to deal
with that for the convenience.

(Just saw Orgad's response - that might be cleaner?)

---
Andy Maloney // https://asmaloney.com

Post by Murphy, Sean

Post by Tobias Hunger
That is something that should be done by the build system IMHO

Can you expand on this part? By build system, I assume you mean qmake?
If that's what you meant, I'm all for doing it that way as well, how would I
go about adding what I'm looking for into the .pro file?
Basically, in our current setup, we're all using qmake as the build system,
so if there's a solution that works via qmake variables, I'm totally fine with
that too, I just haven't found them yet if they exist. If it matters, we're
currently targeting Windows (using mingw compiler) and Mac desktops,
but have plans for Android and iOS down the road, so I'd like to have this
be something that is set up once, and then each developer gets it for free
when they clone the Git repo.
As it stands right now, each developer has to manually set these up. Hell,
I even have to manually set it up if I clone my repository on my own
machine. I usually have our release branch checked out in one directory,
and then I clone from there into other directories to create feature
branches. So on that cloned repo, I've temporarily lost those build settings
until I manually re-add them to that cloned directory's .pro.user file,
either by manually copying the previous .pro.user file over, or by using
the Projects pane in Qt Creator to add the steps back in.
I'm also totally open to being told my approach is just completely wrong,
as long as someone has a better approach!
Thanks,
Sean
This message has been scanned for malware by Forcepoint.
www.forcepoint.com
_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator

[Murphy, Sean]

Thanks guys! Actually I think a combination of both your suggestions might work better than what I have currently. What I don’t like about my current setup is that the thing that generates the .h file is an executable – it has to be compiled to work. The only real advantage of that is that it is written in Qt, so it’s cross platform in that sense, but the disadvantage is that it doesn’t exist on a developer’s machine until it itself is compiled. So moving to a script is probably safer. The work it is doing is basically exactly the same as what you have described below.

So my current thought it to use Orgad’s commands in the .pro file, but have two scripts checked in to the project: a bash .sh file for Linux/Mac, and an equivalent .bat file for Windows, and properly platform scope the
git_ver.commands = your-app-that-generates-the-version-header
command in the .pro file. That way I can avoid introducing a Cygwin dependency for the Windows users and still get that Git revision information compiled in automatically.

Sean Murphy
Sr. Project Engineer
Walbro LLC
4144 Doerr Rd
Cass City, MI 48726
ph. 989 872 7274
cell 734 223 8975
fax. [phone]
***@walbro.com<mailto:***@walbro.com>

Confidentiality Notice: The materials contained within this e-mail transmission (including all attachments) are private and confidential and the property of the sender. The information contained in the materials is privileged and intended only for the named addressee(s). If you are not the intended addressee, be advised that any unauthorized disclosure, copying, distribution or the taking of any action in reliance on the contents of this material is strictly prohibited. If you have received this e-mail transmission in error, please immediately notify the sender by telephone at 989-872-7274 or send an e-mail to ***@walbro.com<mailto:***@walbro.com> and thereafter destroy the e-mail you received and all copies thereof.

From: Andy <***@gmail.com>
Sent: Friday, July 06, 2018 11:04 AM
To: Murphy, Sean <***@walbro.com>
Cc: qt-creator <qt-***@qt-project.org>
Subject: Re: [Qt-creator] How to put custom build steps into Git?

For my git info, I am using what feels like a hacky way to avoid having to add pre-build steps on every single project configuration. Might help?

In my .pro:


# Get our build info from git

OTHER_FILES += "$$PWD/gen_header.sh"



!build_pass {

UNUSED_RESULT = $$system(bash "$$PWD/gen_header.sh")

}


And then the contents of gen_header.sh:


#!/bin/bash



(

echo '// Generated by gen_header.sh - do not edit'

echo

echo '#define GIT_VERSION_LONG "'`git describe --long`'"'

echo '#define GIT_VERSION_HASH "'`git log --pretty=format:'%h' -n 1`'"'

echo

echo '#define GIT_BUILD_DATE_LONG "'`git log -n 1 --format=%ai`'"'

echo '#define GIT_BUILD_DATE_SHORT "'`git log -n 1 --format=%ad --date=short`'"'

) > gitVersion.h


On Windows I have cygwin installed, so bash may be found. Maybe this trades one type of config for another, but I already use cygwin for many things so I have it installed on all my Windows build machines.

Another limitation is that it executes every build, but I'm willing to deal with that for the convenience.

(Just saw Orgad's response - that might be cleaner?)

---
Andy Maloney // https://asmaloney.com

Post by Tobias Hunger
That is something that should be done by the build system IMHO

Can you expand on this part? By build system, I assume you mean qmake?
If that's what you meant, I'm all for doing it that way as well, how would I
go about adding what I'm looking for into the .pro file?

Basically, in our current setup, we're all using qmake as the build system,
so if there's a solution that works via qmake variables, I'm totally fine with
that too, I just haven't found them yet if they exist. If it matters, we're
currently targeting Windows (using mingw compiler) and Mac desktops,
but have plans for Android and iOS down the road, so I'd like to have this
be something that is set up once, and then each developer gets it for free
when they clone the Git repo.

As it stands right now, each developer has to manually set these up. Hell,
I even have to manually set it up if I clone my repository on my own
machine. I usually have our release branch checked out in one directory,
and then I clone from there into other directories to create feature
branches. So on that cloned repo, I've temporarily lost those build settings
until I manually re-add them to that cloned directory's .pro.user file,
either by manually copying the previous .pro.user file over, or by using
the Projects pane in Qt Creator to add the steps back in.

I'm also totally open to being told my approach is just completely wrong,
as long as someone has a better approach!

Thanks,
Sean



This message has been scanned for malware by Forcepoint. www.forcepoint.com<http://www.forcepoint.com>
_______________________________________________
Qt-creator mailing list
Qt-***@qt-project.org<mailto:Qt-***@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/qt-creator


Click here<https://www.mailcontrol.com/sr/zKzqaFWSOmnGX2PQPOmvUihCLhWP7Wj9Y0v96vjA5EQF7ehvCj0SGQIR3mYxpY8g4Qm!sxyzaeH3KeH4!zzvzA==> to report this email as spam.

[Orgad Shaneh]

Post by Murphy, Sean
Thanks guys! Actually I think a combination of both your suggestions might
work better than what I have currently. What I don’t like about my current
setup is that the thing that generates the .h file is an executable – it
has to be compiled to work. The only real advantage of that is that it is
written in Qt, so it’s cross platform in that sense, but the disadvantage
is that it doesn’t exist on a developer’s machine until it itself is
compiled. So moving to a script is probably safer. The work it is doing is
basically exactly the same as what you have described below.
So my current thought it to use Orgad’s commands in the .pro file, but
have two scripts checked in to the project: a bash .sh file for
Linux/Mac, and an equivalent .bat file for Windows, and properly platform
scope the
git_ver.commands = your-app-that-generates-the-version-header
command in the .pro file. That way I can avoid introducing a Cygwin
dependency for the Windows users and still get that Git revision
information compiled in automatically.

If you can deploy to some directory in the PATH, you can create a shell
script named git-apply-version, place it in a directory in the PATH and
execute it as "git apply-version". This should work on all platforms
without extra dependencies.

- Orgad

[Andy]

Another thing I didn't mention is that if you want to avoid rebuilding
files, the script can be smarter.

Generate to a temporary file and only copy it over the existing one if it
is different.

I didn't bother for my setup because the header is only included in one
place and only rebuilds a small file.

---
Andy Maloney // https://asmaloney.com

Post by Murphy, Sean
Thanks guys! Actually I think a combination of both your suggestions might
work better than what I have currently. What I don’t like about my current
setup is that the thing that generates the .h file is an executable – it
has to be compiled to work. The only real advantage of that is that it is
written in Qt, so it’s cross platform in that sense, but the disadvantage
is that it doesn’t exist on a developer’s machine until it itself is
compiled. So moving to a script is probably safer. The work it is doing is
basically exactly the same as what you have described below.
So my current thought it to use Orgad’s commands in the .pro file, but
have two scripts checked in to the project: a bash .sh file for
Linux/Mac, and an equivalent .bat file for Windows, and properly platform
scope the
git_ver.commands = your-app-that-generates-the-version-header
command in the .pro file. That way I can avoid introducing a Cygwin
dependency for the Windows users and still get that Git revision
information compiled in automatically.
*Sean Murphy*
Sr. Project Engineer
Walbro LLC
4144 Doerr Rd
Cass City, MI 48726
ph. 989 872 7274
cell 734 223 8975
fax. [phone]
*Confidentiality Notice:* The materials contained within this e-mail
transmission (including all attachments) are private and confidential and
the property of the sender. The information contained in the materials is
privileged and intended only for the named addressee(s). If you are not the
intended addressee, be advised that any unauthorized disclosure, copying,
distribution or the taking of any action in reliance on the contents of
this material is strictly prohibited. If you have received this e-mail
transmission in error, please immediately notify the sender by telephone at
destroy the e-mail you received and all copies thereof.
*Sent:* Friday, July 06, 2018 11:04 AM
*Subject:* Re: [Qt-creator] How to put custom build steps into Git?
For my git info, I am using what feels like a hacky way to avoid having
to add pre-build steps on every single project configuration. Might help?
# Get our build info from git
OTHER_FILES += "$$PWD/gen_header.sh"
!build_pass {
UNUSED_RESULT = $$system(bash "$$PWD/gen_header.sh")
}
#!/bin/bash
(
echo '// Generated by gen_header.sh - do not edit'
echo
echo '#define GIT_VERSION_LONG "'`git describe --long`'"'
echo '#define GIT_VERSION_HASH "'`git log --pretty=format:'%h' -n 1`'"'
echo
echo '#define GIT_BUILD_DATE_LONG "'`git log -n 1 --format=%ai`'"'
echo '#define GIT_BUILD_DATE_SHORT "'`git log -n 1 --format=%ad --date=short`'"'
) > gitVersion.h
On Windows I have cygwin installed, so bash may be found. Maybe this
trades one type of config for another, but I already use cygwin for many
things so I have it installed on all my Windows build machines.
Another limitation is that it executes every build, but I'm willing to
deal with that for the convenience.
(Just saw Orgad's response - that might be cleaner?)
---
Andy Maloney // https://asmaloney.com

Post by Tobias Hunger
That is something that should be done by the build system IMHO

Can you expand on this part? By build system, I assume you mean qmake?
If that's what you meant, I'm all for doing it that way as well, how would I
go about adding what I'm looking for into the .pro file?
Basically, in our current setup, we're all using qmake as the build system,
so if there's a solution that works via qmake variables, I'm totally fine with
that too, I just haven't found them yet if they exist. If it matters, we're
currently targeting Windows (using mingw compiler) and Mac desktops,
but have plans for Android and iOS down the road, so I'd like to have this
be something that is set up once, and then each developer gets it for free
when they clone the Git repo.
As it stands right now, each developer has to manually set these up. Hell,
I even have to manually set it up if I clone my repository on my own
machine. I usually have our release branch checked out in one directory,
and then I clone from there into other directories to create feature
branches. So on that cloned repo, I've temporarily lost those build settings
until I manually re-add them to that cloned directory's .pro.user file,
either by manually copying the previous .pro.user file over, or by using
the Projects pane in Qt Creator to add the steps back in.
I'm also totally open to being told my approach is just completely wrong,
as long as someone has a better approach!
Thanks,
Sean
This message has been scanned for malware by Forcepoint.
www.forcepoint.com
_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator
Click here
<https://www.mailcontrol.com/sr/zKzqaFWSOmnGX2PQPOmvUihCLhWP7Wj9Y0v96vjA5EQF7ehvCj0SGQIR3mYxpY8g4Qm!sxyzaeH3KeH4!zzvzA==>
to report this email as spam.
_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator

[Murphy, Sean]

Yeah, that’s what my current .exe does, it grabs the information from Git and parses the previously existing version.h (if one exists), only over-writing that header file if the Git information has changed from what’s in the file. Thus preventing a recompile of the much larger .cpp file that includes the version.h file.

I also only put this in the Release target, as I really don’t care about this info when I’m building in debug mode. But that can be scoped in/out in the .pro file as well.

Sean Murphy
Sr. Project Engineer
Walbro LLC
4144 Doerr Rd
Cass City, MI 48726
ph. 989 872 7274
cell 734 223 8975
fax. [phone]
***@walbro.com<mailto:***@walbro.com>

Confidentiality Notice: The materials contained within this e-mail transmission (including all attachments) are private and confidential and the property of the sender. The information contained in the materials is privileged and intended only for the named addressee(s). If you are not the intended addressee, be advised that any unauthorized disclosure, copying, distribution or the taking of any action in reliance on the contents of this material is strictly prohibited. If you have received this e-mail transmission in error, please immediately notify the sender by telephone at 989-872-7274 or send an e-mail to ***@walbro.com<mailto:***@walbro.com> and thereafter destroy the e-mail you received and all copies thereof.

From: Andy <***@gmail.com>
Sent: Friday, July 06, 2018 12:02 PM
To: Murphy, Sean <***@walbro.com>
Cc: qt-creator <qt-***@qt-project.org>
Subject: Re: [Qt-creator] How to put custom build steps into Git?

Another thing I didn't mention is that if you want to avoid rebuilding files, the script can be smarter.

Generate to a temporary file and only copy it over the existing one if it is different.

I didn't bother for my setup because the header is only included in one place and only rebuilds a small file.

---
Andy Maloney // https://asmaloney.com
twitter ~ @asmaloney<https://twitter.com/asmaloney>



On Fri, Jul 6, 2018 at 11:47 AM Murphy, Sean <***@walbro.com<mailto:***@walbro.com>> wrote:
Thanks guys! Actually I think a combination of both your suggestions might work better than what I have currently. What I don’t like about my current setup is that the thing that generates the .h file is an executable – it has to be compiled to work. The only real advantage of that is that it is written in Qt, so it’s cross platform in that sense, but the disadvantage is that it doesn’t exist on a developer’s machine until it itself is compiled. So moving to a script is probably safer. The work it is doing is basically exactly the same as what you have described below.

So my current thought it to use Orgad’s commands in the .pro file, but have two scripts checked in to the project: a bash .sh file for Linux/Mac, and an equivalent .bat file for Windows, and properly platform scope the
git_ver.commands = your-app-that-generates-the-version-header
command in the .pro file. That way I can avoid introducing a Cygwin dependency for the Windows users and still get that Git revision information compiled in automatically.

Sean Murphy
Sr. Project Engineer
Walbro LLC
4144 Doerr Rd
Cass City, MI 48726
ph. 989 872 7274
cell 734 223 8975
fax. [phone]
***@walbro.com<mailto:***@walbro.com>

Confidentiality Notice: The materials contained within this e-mail transmission (including all attachments) are private and confidential and the property of the sender. The information contained in the materials is privileged and intended only for the named addressee(s). If you are not the intended addressee, be advised that any unauthorized disclosure, copying, distribution or the taking of any action in reliance on the contents of this material is strictly prohibited. If you have received this e-mail transmission in error, please immediately notify the sender by telephone at 989-872-7274 or send an e-mail to ***@walbro.com<mailto:***@walbro.com> and thereafter destroy the e-mail you received and all copies thereof.

From: Andy <***@gmail.com<mailto:***@gmail.com>>
Sent: Friday, July 06, 2018 11:04 AM
To: Murphy, Sean <***@walbro.com<mailto:***@walbro.com>>
Cc: qt-creator <qt-***@qt-project.org<mailto:qt-***@qt-project.org>>
Subject: Re: [Qt-creator] How to put custom build steps into Git?

For my git info, I am using what feels like a hacky way to avoid having to add pre-build steps on every single project configuration. Might help?

In my .pro:


# Get our build info from git

OTHER_FILES += "$$PWD/gen_header.sh"



!build_pass {

UNUSED_RESULT = $$system(bash "$$PWD/gen_header.sh")

}


And then the contents of gen_header.sh:


#!/bin/bash



(

echo '// Generated by gen_header.sh - do not edit'

echo

echo '#define GIT_VERSION_LONG "'`git describe --long`'"'

echo '#define GIT_VERSION_HASH "'`git log --pretty=format:'%h' -n 1`'"'

echo

echo '#define GIT_BUILD_DATE_LONG "'`git log -n 1 --format=%ai`'"'

echo '#define GIT_BUILD_DATE_SHORT "'`git log -n 1 --format=%ad --date=short`'"'

) > gitVersion.h


On Windows I have cygwin installed, so bash may be found. Maybe this trades one type of config for another, but I already use cygwin for many things so I have it installed on all my Windows build machines.

Another limitation is that it executes every build, but I'm willing to deal with that for the convenience.

(Just saw Orgad's response - that might be cleaner?)

---
Andy Maloney // https://asmaloney.com

Post by Tobias Hunger
That is something that should be done by the build system IMHO

Can you expand on this part? By build system, I assume you mean qmake?
If that's what you meant, I'm all for doing it that way as well, how would I
go about adding what I'm looking for into the .pro file?

Basically, in our current setup, we're all using qmake as the build system,
so if there's a solution that works via qmake variables, I'm totally fine with
that too, I just haven't found them yet if they exist. If it matters, we're
currently targeting Windows (using mingw compiler) and Mac desktops,
but have plans for Android and iOS down the road, so I'd like to have this
be something that is set up once, and then each developer gets it for free
when they clone the Git repo.

As it stands right now, each developer has to manually set these up. Hell,
I even have to manually set it up if I clone my repository on my own
machine. I usually have our release branch checked out in one directory,
and then I clone from there into other directories to create feature
branches. So on that cloned repo, I've temporarily lost those build settings
until I manually re-add them to that cloned directory's .pro.user file,
either by manually copying the previous .pro.user file over, or by using
the Projects pane in Qt Creator to add the steps back in.

I'm also totally open to being told my approach is just completely wrong,
as long as someone has a better approach!

Thanks,
Sean



This message has been scanned for malware by Forcepoint. www.forcepoint.com<http://www.forcepoint.com>
_______________________________________________
Qt-creator mailing list
Qt-***@qt-project.org<mailto:Qt-***@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/qt-creator


Click here<https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==> to report this email as spam.
_______________________________________________
Qt-creator mailing list
Qt-***@qt-project.org<mailto:Qt-***@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/qt-creator

[Murphy, Sean]

Can you make use of the .pro.shared file for that?
http://doc.qt.io/qtcreator/creator-sharing-project-settings.html

I just stumbled across that option yesterday, and I'm trying to work through it
to see if it works. Based on where those values are placed in the .pro.user file,
I'm not sure if it's going to work, as it seems like the XML chunk I need to copy
out of the .pro.user also contains some absolute paths as well as includes things
like the targeted Qt version. For the project we're working on, we don't have a
hard requirement that all developers must be using the same Qt version, and
the stuff I'm trying to put into the shared settings certainly doesn't depend on
Qt versions at all. But I'm not sure that I can chunk out what I need in a sensible
way that will work on someone else's machine.

I'll post back once I know more...

Sean


This message has been scanned for malware by Forcepoint. www.forcepoint.com

[Orgad Shaneh]

Post by Murphy, Sean

Can you make use of the .pro.shared file for that?
http://doc.qt.io/qtcreator/creator-sharing-project-settings.html

I just stumbled across that option yesterday, and I'm trying to work through it
to see if it works. Based on where those values are placed in the .pro.user file,
I'm not sure if it's going to work, as it seems like the XML chunk I need to copy
out of the .pro.user also contains some absolute paths as well as includes things
like the targeted Qt version. For the project we're working on, we don't have a
hard requirement that all developers must be using the same Qt version, and
the stuff I'm trying to put into the shared settings certainly doesn't depend on
Qt versions at all. But I'm not sure that I can chunk out what I need in a sensible
way that will work on someone else's machine.
I'll post back once I know more...

If you want to use a shared file, you'll need to deploy shared kits for all
the developers. This can be done using sdktool. We've been using it for
years, and it works well (although not easy to maintain, for example when
adding a build configuration to the shared file...)

But I agree with Tobias. Your requirements are easier to do by using the
build system itself instead of Qt Creator.

- Orgad

[Tobias Hunger]

On Fri, Jul 6, 2018, 08:02 Guenter Schwann via Qt-creator <

Can you make use of the .pro.shared file for that?
http://doc.qt.io/qtcreator/creator-sharing-project-settings.html

Good idea, but that will only work if you can make sure every developer has
the same kits. The only way to do that is with the SDK tool, since there is
no way to force the Kit's ID via the UI. They use UUIDs...

So if you can make sure every developer as his environment set up by an
installer running sdktool for them and that nobody will ever use self-made
kits, then you can use shared settings. Otherwise you can't.

Best regards,
Tobias