>Hi Barbara, Hi Tobias,
> >> I think of basic project situation which I work with right now: >> >> - I develop a custom Qt plugin >> - I have to copy my dll to a specific folder for execution by a >> plugins host > >That is a task the build system should handle (via "make install" or similar >that should then go into the deploy configuration). OK, I meant during development and local testing by developer. >> - An environment variable is used for base path of commands > > configured in build/run settings > >Who sets this variable? Every developer. > >> So if anyone else works on project it would be fine that: >> >> - when reconfiguring project since his/her kit is slightly different >> from > > mine, all the other things are kept > > (build/run custom commands). I didn't verify what happens > >If the kits are identical (incl. the Id, which you can set via the sdktool >only!), then this should work using the .shared files. So let's concentrate on >the case where the kits differ. > >Currently we have a kit id in the .user file and nothing else. So there is no >way to know what a kit looked like that somebody else referenced in a .user >file. Adding that information is not of course possible though. > >Let's assume we had full information on the kits that were used by the >instance that wrote the .user file. How can we decide which of our kits are >the best match to those found in the .user file? > >Which of our kits are "slightly different" (as in we want to copy the settings >from the .user file) and which are "completely different" (as in we want to >forget those settings) compared to those found in a .user file? > >Is a Qt 5.0.0 windows MSVC2012 kit "slightly different" (as in we want to copy >settings) from a desktop Qt 4.8.5 windows MSVC2012 kit? > >What about Qt 5.2.1 for blackberry and a Qt 5.2.1 for ubuntu phone kit? > >Qt 5.2.1 on the Mac and Qt 5.2.0 on Linux? > >Qt 5.2.1 windows MSVC2012 and Qt 5.2.1 windows mingw? I totally agree, kits cannot be guessed nor shared, only customized build/run commands. > >> - timestamp change wouldn't be effective so often, only when there > > are modifications, this would be better when > > working with version control. > >Do not check in .user files into your version control system. Use .shared >files for those settings that can be shared. This currently does >*not* include the kits though. > Totally agree. >> So my suggestion is to move commands to another file than the user > > settings, surely in a custom syntax in .pro file. > >Like the .shared file? Totally right. > >Creator supports several build systems, so I would really appreciate not >mixing our settings into the build system files. We would need to have several >sets of code to put that information into the build systems and to retrieve it >again. > > > This way we could > > also have build/run commands way more flexible (use of environment > > > variables, not just elimited to sourceDir andbuildDir). > >Creator actually does support quite a bit more than that. > >> And keep other things in .pro.user that would be safely ignored by > > version control without loosing information. >> >> This idea came to me immediately after playing with build/run >> settings, > > I told myself, duh this is not as convenient as in Visual Studio > (where > > I daily practice C#). > >You are probably right, but this cross-platform thing makes this whole thing a >bit harder. Of course that is no excuse not to do the right thing(TM). > I agree, I don't know much anyways, just beginner thoughts. >Best Regards, >Tobias > Best regards, Barbara _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
