Re: [Qt-creator] New EnvironmentId variable in .creator.user files
On 17.09.2010 20:33, ext Bryce Schober wrote: I'm extremely disappointed. I'm using Qt Creator exclusively for generic Makefile development. It has had its warts for that purpose, but this makes it much worse, because now there is no way for me to share build configurations with others. What could be done to improve your use case? So you just want a set of additional make targets to be (pre-)defined for users as well as a list of things that can be run? Would it help if we added some more files to make those known to creator? This is going to completely kill my usage scenario if it continues. What is you usage scenario? From our point of view we are not continuing, but just made our users aware about something that has never worked before. We had lots of complaints about trouble due to sharing a .user-file. Since there is little we can do to make it share better we had to at least provide a warning. Maybe this is just one of those you're not our customer situations, but it's pretty disappointing. Now generic project support is even more of an orphan than it was. We are willing to accept merge requests to improve any part of creator including the different build system integrations. Unfortunately we do not have much time ourselves to improve the generic project support:-( Some of us are using the generic project to contribute to open source projects that are not qmake based, so it is regularly excersied and tested and we do make sure to not break those use cases. Best Regards, Tobias -- Tobias Hunger Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] New EnvironmentId variable in .creator.user files
Without wanting to say anything on behalf of others, let me just give my personal 2 cents. We develop based on CMake projects with a group of people and with shadow builds. Most of us use Qt Creator, this works quite well. The only thing that is a hassle is the .user file and the settings therein. When we quickly want to hand over a project, we pack the root directory of the source tree, i.e., the one that also holds the CMakeLists.txt. Unfortunately, also the CMakeLists.txt.user file is located here, and hence it gets distributed. This is a pain, because the build-directory and run-working-directory could (so far) not be defined relative to a user-defined location and/or an environment variable. Fortunately, this has been fixed quickly after I reported this (http://bugreports.qt.nokia.com/browse/QTCREATORBUG-2377), thanks for that. From the discussion above, I have learned that we should just not distribute the .user file. From my perspective, it would be preferable to have the build settings and run settings removed from the .user file and store these in separate files like you suggested, which then can be saved in the source tree. I would suggest then that the .user file is stored in the build directory, not in the source tree. I will consider making patches if this is something that people would like to have. However, I am not familiar with the internals of Qt Creator so far, so it would take me a while and I'm not sure about the quality... Regards, Theo. 2010/9/20 Tobias Hunger tobias.hun...@nokia.com: On 17.09.2010 20:33, ext Bryce Schober wrote: I'm extremely disappointed. I'm using Qt Creator exclusively for generic Makefile development. It has had its warts for that purpose, but this makes it much worse, because now there is no way for me to share build configurations with others. What could be done to improve your use case? So you just want a set of additional make targets to be (pre-)defined for users as well as a list of things that can be run? Would it help if we added some more files to make those known to creator? This is going to completely kill my usage scenario if it continues. What is you usage scenario? From our point of view we are not continuing, but just made our users aware about something that has never worked before. We had lots of complaints about trouble due to sharing a .user-file. Since there is little we can do to make it share better we had to at least provide a warning. Maybe this is just one of those you're not our customer situations, but it's pretty disappointing. Now generic project support is even more of an orphan than it was. We are willing to accept merge requests to improve any part of creator including the different build system integrations. Unfortunately we do not have much time ourselves to improve the generic project support:-( Some of us are using the generic project to contribute to open source projects that are not qmake based, so it is regularly excersied and tested and we do make sure to not break those use cases. Best Regards, Tobias -- Tobias Hunger Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] New EnvironmentId variable in .creator.user files
From my perspective, it would be preferable to have the build settings and run settings removed from the .user file and store these in separate files like you suggested, which then can be saved in the source tree. I would suggest then that the .user file is stored in the build directory, not in the source tree. I like your thinking, but the build directory isn't a singular location. Creator uses different build directories based on what you're building for, to allow you to have (for example) a desktop build and a mobile simulator build. /s/ Adam ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] New EnvironmentId variable in .creator.user files
Well, I wasn't planning on a treatise, but I guess that's what we got: On Mon, Sep 20, 2010 at 1:24 AM, Tobias Hunger tobias.hun...@nokia.comwrote: What is you usage scenario? I'm using Qt Creator alongside a complex set of legacy makefiles. Their arrangement isn't straightforward to something like Qt Creator, but works ok from the command line if you can remember where you need to be in the multi-product/multi-target hierarchy. Each product has its own Makefile, with usually at least two different applications for that product, each linking in a common boot-loader that is built separately. Because of this complexity of targets for each product, we also have a top-level Makefile that is used to organize them, so that the user can simply make all targets for product foo, building the individual applications, linking them to the boot-loader, and creating all the final deliverables. So I eventually decided to create one Qt Creator project for each low-level target, which means that for a simple product with two applications and a shared boot-loader, I have three different projects. This decision was driven by a couple factors. First, Qt Creator's highlighting and find features enforce a very narrow perspective of the source code. This has very distinct benefits, which I like. But it also has the drawback of pushing me to separate projects for each application target, even if the only difference is Makefile-driven command-line #defines. (Qt Creator doesn't have per-configuration includes or defines, unlike some IDEs). Fortunately, each of these targets already had separate output directories and automatic dependency generation. So I wrote a shell script that slurps up all the source dependency information and updates the project.files list. This works reasonably well, but has to warn the user to re-load the project.files file, since that isn't re-loaded automatically. Because it's an extra warning, I hid that from non-Qt-creator users by doing the project.files update as a separate build step. What could be done to improve your use case? It would be nice to prompt to re-load project files when edited externally, even if they're not open. Then my project file updating could be silent on the command line. The sheer number of projects resulting from the above constraints is a bit overwhelming, and if they had to be set up by each user in each of their branch sandboxes, using Qt creator for frequent development would never get off the ground. Also, as you'll note above, the application gets built separately from the boot-loader, and then linked as a new combined target. This leads to a lot of inter-project dependencies that are currently impossible to share between users. This is actually what has stalled my roll-out of Qt Creator as the preferred IDE for developers in our organization. Qt Creator really needs some way to express a workspace of project and their dependencies in a way that can be resident in the source tree and independent of physical location. I'm really conflicted about Qt Creator, because it has so much to offer as an clean simple editor, but also with the sophistication that can make the developer's like so much easier with good code completion, refactoring, and a good debugger interface. But as I continue to use it and live with the warts that keep me from promoting it to everyone, I feel that its roots may just be too deeply rooted in the Qt world to work for us (without converting all our Makefiles to QMake). Its handling of Makefile projects is decidedly second-class, and that makes perfect sense, as its primary purpose is as a QT IDE. I guess the compromises are what keep it from becoming the bloated whale that is Eclipse. I would *so much* like it to be able to be a better general-purpose C/C++ IDE, but I simply can't justify spending much more time with it. -- Bryce Schober P.S. If we hypothetically did convert our Makefiles to use QMake and Qt Creator for active development, would that obligate us under the full Qt licensing scheme, or not? ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] New EnvironmentId variable in .creator.user files
P.S. If we hypothetically did convert our Makefiles to use QMake and Qt Creator for active development, would that obligate us under the full Qt licensing scheme, or not? Of course not, not any more than you're subject to the license of GNU Make if you use that to compile your application. Obviously you have to comply with the licensing if you're distributing qmake and Creator themselves but the products you produce using them don't include any part of the build tools themselves. /s/ Adam ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] New EnvironmentId variable in .creator.user files
On 16.09.2010 20:46, ext Bryce Schober wrote: Since switching to the head nightlies, my .creator.user files (Generic projects) now have a ProjectExplorer.Project.Updater.EnvironmentId variable that is changing when nothing else is. The ID is used to check which Creator last opened the file. This is to warn about people using the same .user-file in different environments (OSes, computers, etc.). This is going to pretty annoying if it continues to clutter my check-ins. In addition to cluttering up your checkins it should also trigger warnings about sharing a .user-file when loading the project. Please do not check in the .user file. It is highly dependent on the environment and can not get savely shared! Best Regards, Tobias PS: Having an unique ID is a privacy concern, so I want to point out that we do *NOT* use the ID anywhere but in the .user-file and that this is the only UUID we generate. We have thought hard on how to avoid generating one in the first place. Unfortunately this seems to be the only robust way to warn about sharing .user-files. -- Tobias Hunger Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] New EnvironmentId variable in .creator.user files
I understand that the .pro.user should be shared between users but the build and run settings are stored in pro.user. I want a feature in qtcreator that allows build/run settings in terms of and environmental that any user can setup appropriately and build/run settings can be made part of .pro so that they can be shared. ie. The build directory could be something like $BLDDIR/projectname and user can setup $BLDDIR to desired value before starting Qt Creator and similarly executable to be run in the run settings would be specified as $BLDDIR/projectname/executablename. Regards Anshul On Fri, Sep 17, 2010 at 3:31 PM, Tobias Hunger tobias.hun...@nokia.comwrote: On 16.09.2010 20:46, ext Bryce Schober wrote: Since switching to the head nightlies, my .creator.user files (Generic projects) now have a ProjectExplorer.Project.Updater.EnvironmentId variable that is changing when nothing else is. The ID is used to check which Creator last opened the file. This is to warn about people using the same .user-file in different environments (OSes, computers, etc.). This is going to pretty annoying if it continues to clutter my check-ins. In addition to cluttering up your checkins it should also trigger warnings about sharing a .user-file when loading the project. Please do not check in the .user file. It is highly dependent on the environment and can not get savely shared! Best Regards, Tobias PS: Having an unique ID is a privacy concern, so I want to point out that we do *NOT* use the ID anywhere but in the .user-file and that this is the only UUID we generate. We have thought hard on how to avoid generating one in the first place. Unfortunately this seems to be the only robust way to warn about sharing .user-files. -- Tobias Hunger Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] New EnvironmentId variable in .creator.user files
A properly configured .pro file should be able to satisfy your needs; Qt is designed to be able to handle building apps at the command line without needing to use Creator at all, and that doesn't use the .pro.user file, so you should be able to put all of the necessary configuration in the .pro file. /s/ Adam On Fri, Sep 17, 2010 at 5:17 AM, anshul mehta ansme...@gmail.com wrote: I understand that the .pro.user should be shared between users but the build and run settings are stored in pro.user. I want a feature in qtcreator that allows build/run settings in terms of and environmental that any user can setup appropriately and build/run settings can be made part of .pro so that they can be shared. ie. The build directory could be something like $BLDDIR/projectname and user can setup $BLDDIR to desired value before starting Qt Creator and similarly executable to be run in the run settings would be specified as $BLDDIR/projectname/executablename. Regards Anshul On Fri, Sep 17, 2010 at 3:31 PM, Tobias Hunger tobias.hun...@nokia.com wrote: On 16.09.2010 20:46, ext Bryce Schober wrote: Since switching to the head nightlies, my .creator.user files (Generic projects) now have a ProjectExplorer.Project.Updater.EnvironmentId variable that is changing when nothing else is. The ID is used to check which Creator last opened the file. This is to warn about people using the same .user-file in different environments (OSes, computers, etc.). This is going to pretty annoying if it continues to clutter my check-ins. In addition to cluttering up your checkins it should also trigger warnings about sharing a .user-file when loading the project. Please do not check in the .user file. It is highly dependent on the environment and can not get savely shared! Best Regards, Tobias PS: Having an unique ID is a privacy concern, so I want to point out that we do *NOT* use the ID anywhere but in the .user-file and that this is the only UUID we generate. We have thought hard on how to avoid generating one in the first place. Unfortunately this seems to be the only robust way to warn about sharing .user-files. -- Tobias Hunger Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] New EnvironmentId variable in .creator.user files
I'm extremely disappointed. I'm using Qt Creator exclusively for generic Makefile development. It has had its warts for that purpose, but this makes it much worse, because now there is no way for me to share build configurations with others. This is going to completely kill my usage scenario if it continues. Maybe this is just one of those you're not our customer situations, but it's pretty disappointing. Now generic project support is even more of an orphan than it was. On Fri, Sep 17, 2010 at 7:28 AM, Coda Highland c...@bobandgeorge.comwrote: A properly configured .pro file should be able to satisfy your needs; Qt is designed to be able to handle building apps at the command line without needing to use Creator at all, and that doesn't use the .pro.user file, so you should be able to put all of the necessary configuration in the .pro file. /s/ Adam On Fri, Sep 17, 2010 at 5:17 AM, anshul mehta ansme...@gmail.com wrote: I understand that the .pro.user should be shared between users but the build and run settings are stored in pro.user. I want a feature in qtcreator that allows build/run settings in terms of and environmental that any user can setup appropriately and build/run settings can be made part of .pro so that they can be shared. ie. The build directory could be something like $BLDDIR/projectname and user can setup $BLDDIR to desired value before starting Qt Creator and similarly executable to be run in the run settings would be specified as $BLDDIR/projectname/executablename. Regards Anshul On Fri, Sep 17, 2010 at 3:31 PM, Tobias Hunger tobias.hun...@nokia.com wrote: On 16.09.2010 20:46, ext Bryce Schober wrote: Since switching to the head nightlies, my .creator.user files (Generic projects) now have a ProjectExplorer.Project.Updater.EnvironmentId variable that is changing when nothing else is. The ID is used to check which Creator last opened the file. This is to warn about people using the same .user-file in different environments (OSes, computers, etc.). This is going to pretty annoying if it continues to clutter my check-ins. In addition to cluttering up your checkins it should also trigger warnings about sharing a .user-file when loading the project. Please do not check in the .user file. It is highly dependent on the environment and can not get savely shared! Best Regards, Tobias PS: Having an unique ID is a privacy concern, so I want to point out that we do *NOT* use the ID anywhere but in the .user-file and that this is the only UUID we generate. We have thought hard on how to avoid generating one in the first place. Unfortunately this seems to be the only robust way to warn about sharing .user-files. -- Tobias Hunger Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator -- Bryce Schober ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] New EnvironmentId variable in .creator.user files
If that is the case, what is the purpose of the pro.user files? On Fri, Sep 17, 2010 at 7:28 AM, Coda Highland c...@bobandgeorge.com wrote: A properly configured .pro file should be able to satisfy your needs; Qt is designed to be able to handle building apps at the command line without needing to use Creator at all, and that doesn't use the .pro.user file, so you should be able to put all of the necessary configuration in the .pro file. /s/ Adam ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] New EnvironmentId variable in .creator.user files
For local, per-machine settings that you would otherwise provide on the qmake command line (i.e. it would store macx-g++42 where you might type qmake -spec macx-g++42 -- you wouldn't WANT to store this in the project though since it would be WRONG for anyone not running Mac), and to store things like editor layouts and other IDE settings that aren't actually part of the project but rather part of your personal environment. /s/ Adam On Fri, Sep 17, 2010 at 2:13 PM, Danny Price deepblue...@googlemail.com wrote: If that is the case, what is the purpose of the pro.user files? On Fri, Sep 17, 2010 at 7:28 AM, Coda Highland c...@bobandgeorge.com wrote: A properly configured .pro file should be able to satisfy your needs; Qt is designed to be able to handle building apps at the command line without needing to use Creator at all, and that doesn't use the .pro.user file, so you should be able to put all of the necessary configuration in the .pro file. /s/ Adam ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] New EnvironmentId variable in .creator.user files
You know, I have to ask why you feel the need to use a generic project in the first place if you're just going to tie the build system to Creator. Usually people want to use bare Makefiles in order to be able to customize the build process in the makefile itself -- and certainly makefiles are expressive enough to do everything you could possibly want it to do. What part of your use case isn't accommodated here? What is it that you're trying to do that can't be done in the makefile itself? /s/ Adam On Fri, Sep 17, 2010 at 1:33 PM, Bryce Schober bryce.scho...@gmail.com wrote: I'm extremely disappointed. I'm using Qt Creator exclusively for generic Makefile development. It has had its warts for that purpose, but this makes it much worse, because now there is no way for me to share build configurations with others. This is going to completely kill my usage scenario if it continues. Maybe this is just one of those you're not our customer situations, but it's pretty disappointing. Now generic project support is even more of an orphan than it was. On Fri, Sep 17, 2010 at 7:28 AM, Coda Highland c...@bobandgeorge.com wrote: A properly configured .pro file should be able to satisfy your needs; Qt is designed to be able to handle building apps at the command line without needing to use Creator at all, and that doesn't use the .pro.user file, so you should be able to put all of the necessary configuration in the .pro file. /s/ Adam On Fri, Sep 17, 2010 at 5:17 AM, anshul mehta ansme...@gmail.com wrote: I understand that the .pro.user should be shared between users but the build and run settings are stored in pro.user. I want a feature in qtcreator that allows build/run settings in terms of and environmental that any user can setup appropriately and build/run settings can be made part of .pro so that they can be shared. ie. The build directory could be something like $BLDDIR/projectname and user can setup $BLDDIR to desired value before starting Qt Creator and similarly executable to be run in the run settings would be specified as $BLDDIR/projectname/executablename. Regards Anshul On Fri, Sep 17, 2010 at 3:31 PM, Tobias Hunger tobias.hun...@nokia.com wrote: On 16.09.2010 20:46, ext Bryce Schober wrote: Since switching to the head nightlies, my .creator.user files (Generic projects) now have a ProjectExplorer.Project.Updater.EnvironmentId variable that is changing when nothing else is. The ID is used to check which Creator last opened the file. This is to warn about people using the same .user-file in different environments (OSes, computers, etc.). This is going to pretty annoying if it continues to clutter my check-ins. In addition to cluttering up your checkins it should also trigger warnings about sharing a .user-file when loading the project. Please do not check in the .user file. It is highly dependent on the environment and can not get savely shared! Best Regards, Tobias PS: Having an unique ID is a privacy concern, so I want to point out that we do *NOT* use the ID anywhere but in the .user-file and that this is the only UUID we generate. We have thought hard on how to avoid generating one in the first place. Unfortunately this seems to be the only robust way to warn about sharing .user-files. -- Tobias Hunger Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator -- Bryce Schober ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] New EnvironmentId variable in .creator.user files
And the .user files aren't project files. They're intended for local preferences, not global build settings. The one thing Creator could add that would really make a difference would be for Creator to be able to identify build targets in the makefile other than just the default one and clean -- that way you could put all of the relevant logic in the makefile and simply select the appropriate target. You wouldn't be the first user I've talked to that would find this behavior useful -- one of the developers of Leges Motus has expressed that this was the one shortcoming that kept Creator from being suitable for that project. /s/ Adam On Fri, Sep 17, 2010 at 3:35 PM, Bryce Schober bryce.scho...@gmail.com wrote: Well, I suppose it is a bit of a collision between the deficiencies of our Makefiles and Qt Creator... but different build and run modes are nice to remember in a project file. And when they can be reasonably expressed, depending on relative paths or environmental variables to abstract away the user-specificity, then of course you'd want them to be shared. If for no other reason than that it's a pain for even a single user to copy them around when they're maintaining multiple sandboxes. On Fri, Sep 17, 2010 at 1:02 PM, Coda Highland c...@bobandgeorge.com wrote: You know, I have to ask why you feel the need to use a generic project in the first place if you're just going to tie the build system to Creator. Usually people want to use bare Makefiles in order to be able to customize the build process in the makefile itself -- and certainly makefiles are expressive enough to do everything you could possibly want it to do. What part of your use case isn't accommodated here? What is it that you're trying to do that can't be done in the makefile itself? /s/ Adam On Fri, Sep 17, 2010 at 1:33 PM, Bryce Schober bryce.scho...@gmail.com wrote: I'm extremely disappointed. I'm using Qt Creator exclusively for generic Makefile development. It has had its warts for that purpose, but this makes it much worse, because now there is no way for me to share build configurations with others. This is going to completely kill my usage scenario if it continues. Maybe this is just one of those you're not our customer situations, but it's pretty disappointing. Now generic project support is even more of an orphan than it was. On Fri, Sep 17, 2010 at 7:28 AM, Coda Highland c...@bobandgeorge.com wrote: A properly configured .pro file should be able to satisfy your needs; Qt is designed to be able to handle building apps at the command line without needing to use Creator at all, and that doesn't use the .pro.user file, so you should be able to put all of the necessary configuration in the .pro file. /s/ Adam On Fri, Sep 17, 2010 at 5:17 AM, anshul mehta ansme...@gmail.com wrote: I understand that the .pro.user should be shared between users but the build and run settings are stored in pro.user. I want a feature in qtcreator that allows build/run settings in terms of and environmental that any user can setup appropriately and build/run settings can be made part of .pro so that they can be shared. ie. The build directory could be something like $BLDDIR/projectname and user can setup $BLDDIR to desired value before starting Qt Creator and similarly executable to be run in the run settings would be specified as $BLDDIR/projectname/executablename. Regards Anshul On Fri, Sep 17, 2010 at 3:31 PM, Tobias Hunger tobias.hun...@nokia.com wrote: On 16.09.2010 20:46, ext Bryce Schober wrote: Since switching to the head nightlies, my .creator.user files (Generic projects) now have a ProjectExplorer.Project.Updater.EnvironmentId variable that is changing when nothing else is. The ID is used to check which Creator last opened the file. This is to warn about people using the same .user-file in different environments (OSes, computers, etc.). This is going to pretty annoying if it continues to clutter my check-ins. In addition to cluttering up your checkins it should also trigger warnings about sharing a .user-file when loading the project. Please do not check in the .user file. It is highly dependent on the environment and can not get savely shared! Best Regards, Tobias PS: Having an unique ID is a privacy concern, so I want to point out that we do *NOT* use the ID anywhere but in the .user-file and that this is the only UUID we generate. We have thought hard on how to avoid generating one in the first place. Unfortunately this seems to be the only robust way to warn about sharing .user-files. -- Tobias Hunger Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin:
