On 12/13/2011 11:19 PM, Michael Hertling wrote: > On 12/13/2011 09:21 PM, David Cole wrote: >> On Tue, Dec 13, 2011 at 2:09 PM, Robert Dailey <rcdai...@gmail.com> 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."
Alternatively, one might add a brief description of the two evaluation kinds right beneath [1] but before [2] and mark the generation-time- evaluated variables with a short tag afterwards. Regards, Michael > [1] http://www.cmake.org/cmake/help/cmake-2-8-docs.html#section_Variables > [2] > http://www.cmake.org/cmake/help/cmake-2-8-docs.html#section_VariablesThatChangeBehavior >>> On Mon, Dec 12, 2011 at 11:26 PM, Michael Wild <them...@gmail.com> 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 <rcdai...@gmail.com >>>>> <mailto:rcdai...@gmail.com>> 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 <rcdai...@gmail.com >>>>> <mailto:rcdai...@gmail.com>> 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 <them...@gmail.com >>>>> <mailto:them...@gmail.com>> wrote: >>>>> >>>>> On 12/12/2011 09:13 PM, Robert Dailey wrote: >>>>> > On Mon, Dec 12, 2011 at 2:10 PM, David Cole >>>>> <david.c...@kitware.com <mailto:david.c...@kitware.com> >>>>> > <mailto:david.c...@kitware.com >>>>> <mailto:david.c...@kitware.com>>> 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