[Cmake] FW: contruction of variable names

[Dekeyser, Kris]

FYI.

I have found a way to get around the problem of nested variable name
evaluation. I rewrote the following macro:

MACRO(LINK_PROJECT ProjectName)
  INCLUDE_DIRECTORIES("${${ProjectName}_SOURCE_DIR}/export/include")
  LINK_DIRECTORIES("${${ProjectName}_BINARY_DIR}/binary/lib")
  LINK_LIBRARIES(${ProjectName})
ENDMACRO(LINK_PROJECT)

and created this one instead:

MACRO(LINK_PROJECT ProjectName)
  FOREACH(Prj ${ProjectName})
    INCLUDE_DIRECTORIES("${${Prj}_SOURCE_DIR}/export/include")
    LINK_DIRECTORIES("${${Prj}_BINARY_DIR}/binary/lib")
    LINK_LIBRARIES(${Prj})
  ENDFOREACH(Prj)
ENDMACRO(LINK_PROJECT)

This works! And in order to add a dependency to another module we now simply
have to add

LINK_PROJECT(OtherProject)

to our CMakeLists.txt

(The example is largely simplified, because our build files take indirect
dependencies into account, inherit special defines, etc. I know, the
PackageConfig.cmake mechanism is available for this, but we created this,
because it is slightly easier to maintain and integrates better with our SCM
environment)

- Kris

> -----Original Message-----
> From: Dekeyser, Kris [mailto:Kris.Dekeyser at lms.be]
> Sent: Thursday, August 19, 2004 22:30
> To: 'Brad King'; William A. Hoffman (E-mail)
> Cc: CMake (E-mail)
> Subject: RE: [Cmake] FW: contruction of variable names
> 
> 
> Hmm,
> 
> It is not that what I am looking for. I am creating sort of 
> configuration
> files to allow other modules to easily configure themselves 
> to link against
> the module. A depending module would simple need to INCLUDE the
> configuration file of the other module.
> 
> The modules each have their own directories with header 
> files, some may
> require specific defines and/or compiler flags, etc. Thats 
> what will be in
> this cmake configuration file. The references are therefore 
> vs the module
> thats is linked in and not the module that is being compiled. 
> In my example
> ${LMSCft_SOURCE_DIR} would do the trick, but under certain 
> circumstances I
> want to revert to generic macros that set a value depending 
> on the library
> thats being configured. eg:
> 
> MACRO(SET_DEF_DIRS)
>   INCLUDE_DIRECTORIES(${${ThisProject}_SOURCE_DIR}/export/include)
>   LINK_DIRECTORIES(${${ThisProject}_BINARY_DIR}/binary/lib)
> ENDMACRO(SET_DEF_DIRS)
> 
> But if the nested variable evaluation is not possible, the 
> MACRO will need
> to accept a set of variables. Not as nice, but possible ...
> 
> Is there a chance that nested variable evaluation could be 
> implemented in a
> future version? Or maybe a function that allows us to retrieve certain
> project variables based on the name of the project? Something like
> GET_DIRECTORY_PROPERTY([DIRECTORY dir] var property) maybe?
> 
> Best regards, Kris
> 
> > -----Original Message-----
> > From: Brad King [mailto:brad.king at kitware.com]
> > Sent: Thursday, August 19, 2004 19:58
> > To: Dekeyser, Kris
> > Cc: CMake (E-mail)
> > Subject: Re: [Cmake] FW: contruction of variable names
> > 
> > 
> > Dekeyser, Kris wrote:
> > > # project's name
> > > SET(ThisProject "LMSCft")
> > > 
> > > #--- exported header files
> > > INCLUDE_DIRECTORIES(${${ThisProject}_SOURCE_DIR}/export/include)
> > 
> > You can use ${PROJECT_SOURCE_DIR} and ${PROJECT_BINARY_DIR} 
> > to refer to 
> > the directories independently of the name of the project.  
> > They refer to 
> > the directories corresponding to the most recent 
> > CMakeLists.txt file to 
> > invoke the PROJECT command.
> > 
> > > But the include directory is "_SOURCE_DIR}/export/include" 
> > in the MSDev
> > > project file. 
> > > I expected to have "<Source dir of the LMSCft 
> > project>/export/include". It
> > > seems as if
> > > the first ${ gets "eaten" by the rest. What did I do wrong?
> > 
> > Nothing.  CMake does not support nested variable name evaluation.
> > 
> > > BTW, in the CMake book (version 1.8) on page 33, the example says:
> > > IF( ${${tfile}}_TEST_RESULT} MATCHES FAILED)
> > 
> > This is not really a nested evaluation.  That is inside a FOREACH 
> > command.  The text "${tfile}" is replaced by FOREACH with 
> the current 
> > iteration's argument before the command is evaluated.
> > 
> > > Notice the unbalanced } due to the double } after tfile. Is 
> > that a typo? 
> > 
> > Yes, that is a typo.
> > 
> > -Brad
> > 
> +-+-+- Email Confidentiality Footer +-+-+- 
> Privileged/Confidential Information may be contained in this 
> message. If you
> are not the addressee indicated in this message (or 
> responsible for delivery
> of the message to such person), you may not print, retain, copy nor
> disseminate this message or any part of it to anyone and you 
> should notify
> the sender by reply email and destroy this message. 
> Neglecting this clause
> could be a breach of confidence. Please advise immediately if 
> you or your
> employer does not consent to Internet email for messages of this kind.
> Opinions, conclusions and other information in this message 
> that are not
> related to the official business of my firm shall be 
> understood as neither
> given nor endorsed by it.
> 
> _______________________________________________
> Cmake mailing list
> Cmake at www.cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
> 
+-+-+- Email Confidentiality Footer +-+-+- 
Privileged/Confidential Information may be contained in this message. If you
are not the addressee indicated in this message (or responsible for delivery
of the message to such person), you may not print, retain, copy nor
disseminate this message or any part of it to anyone and you should notify
the sender by reply email and destroy this message. Neglecting this clause
could be a breach of confidence. Please advise immediately if you or your
employer does not consent to Internet email for messages of this kind.
Opinions, conclusions and other information in this message that are not
related to the official business of my firm shall be understood as neither
given nor endorsed by it.