On Thu, Aug 11, 2011 at 3:51 PM, Alexander Neundorf <neund...@kde.org>wrote:
> On Monday 08 August 2011, Brad King wrote: > > On 8/8/2011 4:24 AM, Johan Björk wrote: > > > This has been discussed a billion times, so I'll keep it short. > > > > > > Problem: Some parts of the build requires a environment variable to be > > > set Solution: Several workarounds, use custom commands, wrapper scripts > > > etc. > > > > > > While the solution works fine for basic stuff, I have several > toolchains > > > > > > etc that requires environment variables to be installed for them to > > > work. > > > > CMake has always assumed that the environment is setup correctly for the > > desired toolchain before either cmake or make runs. Typically developers > > have dealt with this by naming the build tree after the toolchain needed > > as a reminder of the environment needed. I'm sure an alternative would > > be welcomed by many. > > > > > Since I'm using cmake --build for all my building, I am thinking about > > > > > > creating a new command in cmake that will store certain environment > > > variables in the cache, and if building using cmake --build, they will > > > be set before the build starts. > > > > This sounds like a great compromise. I don't think the cache is the > > right place to put this though. I think you can create your own file > > like CMakeFiles/cmake--build.env and give it a format customized for > > this purpose (like one line per variable or something). > > In the Eclipse project generator, I do something similar. > Depending on the used compiler, a set of env.variables are stored in the > cache > and written into the project file, so they will be set when Eclipse invokes > make. > E.g. for the Intel compiler that's the license-related one, for MSVC it's > LIBDIR or something like this. > > Alex > _______________________________________________ > cmake-developers mailing list > cmake-developers@cmake.org > http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers > You could have a "--with-env env.cmake" for the --build stuff. And in the env.cmake file, you could simply have commands of the form: set(ENV{abc} "abc val") set(ENV{xyz} "xyz val") As long as the script is processed in the same CMake process that runs the --build, the environment settings should stick around for the duration of the build. Of course, there's not an easy, existing way to prevent other non-env commands from being executed in such a script. This may or may not be deemed a "good idea," but I figured I had to throw it out there: rather than inventing a whole new way of expressing environment variables in a file, let's use some existing mechanism...
_______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers