On 12/13/2011 09:21 PM, David Cole wrote: > On Tue, Dec 13, 2011 at 2:09 PM, Robert Dailey <[email protected]> wrote: >> Thanks for the info. It's a bit disappointing that it doesn't work like I >> expect. The CMAKE_MFC_FLAG should work as you say the link flags should, but >> it does not. As long as CMAKE_MFC_FLAG is set before I create my target, it >> works. Since CMAKE_SHARED_LINK_FLAGS does not work the same, I consider this >> a bug. There is no reason for it to exist up to the end of the file... it >> should only exist up to the call to create the target. For example, if I >> want to have 2 calls to add_library() in the same file, but specify link >> flags differently for each, how am I expected to do this without using the >> target specific property? > > You're not expected to do that. You should use the target property in > that case. That's what they're there for. > > Or use sub-directory organization to have one target per sub-dir, and > then set the variable appropriately in each sub-dir's CMakeLists file. > > And, there is a reason for it to exist up to the end of the file: it's > called backwards compatibility, and we take it pretty seriously. > > The fact is that some variables are examined at configure-time, while > CMake is processing add_executable and add_library calls, and all the > other myriad commands that are affected by variables values, ... > > ... and some variables are examined later at generate-time, *after* > CMake is done processing the commands, (in other words, "at the end of > the file"). > > So: this particular case may be considered a bug by some, and a > feature by others. Personally, I'm not sure what side of that fence to > fall on. > > However, the primary purpose of this mailing list is to try to show > you how you can do what you want to do with *existing* CMake. We also > like to discuss options and future plans here. > > If you would like to report this as a bug, please feel free to add a > bug report to the bug tracker.
As for me, I wouldn't consider it as a bug, but it should perhaps be mentioned in the documentation which variables undergo this kind of lazy evaluation, i.e. configure-time vs. generate-time evaluation. "This variable is not evaluated until the generation takes place, so the value at the end of the CMakeLists.txt will be in effect." Regards, Michael >> On Mon, Dec 12, 2011 at 11:26 PM, Michael Wild <[email protected]> wrote: >>> >>> It needs to exist **at the end** of the CMakeLists.txt file containing >>> the target. If you don't want to do that (or can't, as in your case), >>> you can use the LINK_FLAGS target property instead. >>> >>> HTH >>> >>> Michael >>> >>> On 12/12/2011 11:39 PM, Robert Dailey wrote: >>>> I have attached a small CMake project that reproduces the issue I'm >>>> referring to. Please take a look :) >>>> >>>> --------- >>>> Robert Dailey >>>> >>>> >>>> On Mon, Dec 12, 2011 at 4:11 PM, Robert Dailey <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> I forgot to say that the main issue is that my /NODEFAULTLIB link >>>> flag isn't showing up in visual studio. >>>> >>>> --------- >>>> Robert Dailey >>>> >>>> >>>> >>>> On Mon, Dec 12, 2011 at 4:10 PM, Robert Dailey <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Another issue... >>>> >>>> At what point is it most important for the values of >>>> CMAKE_SHARED_LINK_FLAGS to exist? I set the value of this >>>> variable before my call to add_library(), however after that at >>>> some point the flags will get reverted because I'm stepping out >>>> of function scope. Does it need to exist up to the end of the >>>> current cmake script? My flow is basically this (pseudo call >>>> stack): >>>> >>>> Enter CMakeLists.txt >>>> - Call define_project() function (in a separate cmake module) >>>> - - Call ignore_libs() function >>>> - - - Set CMAKE_SHARED_LINK_FLAGS with PARENT_SCOPE >>>> - - Call create_target() function >>>> - - - Call add_library() command >>>> Leave CMakeLists.txt >>>> >>>> I've done some testing and I find that before the call to >>>> add_library(), my flags are setup properly in the >>>> CMAKE_SHARED_LINK_FLAGS variable. >>>> >>>> --------- >>>> Robert Dailey >>>> >>>> >>>> >>>> On Mon, Dec 12, 2011 at 2:20 PM, Michael Wild <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> On 12/12/2011 09:13 PM, Robert Dailey wrote: >>>> > On Mon, Dec 12, 2011 at 2:10 PM, David Cole >>>> <[email protected] <mailto:[email protected]> >>>> > <mailto:[email protected] >>>> <mailto:[email protected]>>> wrote: >>>> > >>>> > Apparently, they are undocumented, but there are also: >>>> > >>>> > CMAKE_SHARED_LINKER_FLAGS and >>>> CMAKE_MODULE_LINKER_FLAGS (and their >>>> > per-config variants) for SHARED and MODULE library >>>> targets as well. >>>> > >>>> > Use CMAKE_SHARED_LINKER_FLAGS instead. >>>> > >>>> > >>>> > Thanks for the information guys. I'm having a minor >>>> problem with these >>>> > variables though. >>>> > >>>> > Here is how I use it: >>>> > >>>> > set( CMAKE_SHARED_LINKER_FLAGS >>>> ${CMAKE_SHARED_LINKER_FLAGS} >>>> > /NODEFAULTLIB:\"${lib}\" ) >>>> > >>>> > Prior to calling the set above, the shared linker flags >>>> look like this: >>>> > >>>> > /STACK:10000000 /machine:X86 >>>> > >>>> > After calling the set above, it looks like this: >>>> > >>>> > /STACK:10000000 /machine:X86 ;/NODEFAULTLIB:"LIBC" >>>> > >>>> > For some reason a semi-colon is being inserted prior to >>>> the >>>> > /NODEFAULTLIB part. I don't know why this is happening but >>>> visual studio >>>> > is complaining about it. Any reason why this is happening? >>>> Thanks. >>>> > >>>> >>>> That's how CMake works. >>>> >>>> set(VAR val1 val2 val3) >>>> >>>> defines a *list* where the elements are separated by a >>>> semi-colon (;). >>>> To prevent that, quote the assignment: >>>> >>>> set(VAR "val1 val2 val3") >>>> >>>> >>>> Michael -- 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
