On Mon, 2012-04-02 at 21:57 -0400, Bill Hoffman wrote: > Nothing is perfect. :) Yeah :) Hope you didn't feel offended, which wasn't my intention!
> I was concern about this for a while, Why no longer? > however, we have never seen a > compiler that did not take -D. :) Well I said this, but I guess it's the principle of being portable that should matter here. Actually add_definitions should really allow nothing more than making defines. Actually what I'd prefer most if add_definitions (and perhaps even include_directories) could be set in a per file context[0]. > Actually, I ported to a VMS > compiler once and it used a different flag, but I was able to fix it > from the CMake source level Yeah and that's how things should be... cmake should detect the compiler and see... "ah... compiler 'strangy' ... I need to use -666"... So from the high level point of view (that CMAKE should live on) always specifying -D is pointless (it could be translated anyway)... of course at the moment there is the problem that ANY flags can be set there,... Seems to be a bit unclean to me. > That would be nice, and has been on the todo list for a while. However, > it has never been important enough for someone to actually implement. :-( > > Any ideas?! :-) > Well, you could implement it... :) :D ... yeah... you wouldn't want to know the chain how I came to use CMake (in my current special case I mean, not generally)... it starts somewhere at ganglia is shit -> use Nagios -> is shit -> use Icinga -> need NRPE -> is inherently insecure -> use ssh -> is slow -> find out tweaks to make ssh as fast as NRPE -> great, but need a command restricting shell now -> none found that does the job -> open vi and program yourself -> need a build system.... I wouldn't want to add -> become a CMake hacker ;-) > I would suggest that you move to the discussion to the cmake-developers > list. about doing it... On Tue, 2012-04-03 at 13:41 -0400, Bill Hoffman wrote: > I had another thought on this. Usually it is good enough to build all > of your applications libraries static, and CMake does handle this. If > you use the BUILD_SHARED_LIBS variable in your project you can get it to > build all the libraries as either static or shared based on the value of > this variable. Yeah,.. I've seen that before (but thanks anyway for mentioning an showing the example below) but that affects ALL libs. I mean for the usual suspects why you build statically (independence of the libs for e.g. rescue.tools or speed) you're right and one typically wants everything statically linked. But another scenario is: One or more libs are not available on all systems (e.g. you have old distro x-y-sucks)... I want to link just the missing ones staically, but all others should ideally continue to be used as shared objects. Cheers, Chris. [0] I wrote some (hopefully not interpreted as rant) summary of my first impressions and thoughts about CMake: https://plus.google.com/102329811815220905914/posts/TQsy1WQroJ9
smime.p7s
Description: S/MIME cryptographic signature
-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
