[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cmake
Subject:    [CMake] Generator expressions and rule variables
From:       Kuba Ober <kuba () mareimbrium ! org>
Date:       2019-02-16 4:30:32
Message-ID: CAG4N6cqcYTJsiQeuJVER4L+36NhO=D6wUwR-tm1xraFHJcegHw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Hi, I'm trying to integrate cmake with a set of build tools whose command
lines look nothing like standard gnu tools.

Unfortunately, both the generator expressions and the rule variables seem
very limited: I have to do some custom massaging of the arguments that get
passed to the compiler/linker. I've resorted to using cmake in script mode
as a proxy to the compiler and linker, passing all the rule variables
verbatim, and then having the script call the compiler or linker.

This suffers from problems with escaping of spaces, at the very least. It
seems like those compilation commands would need nested lists (a
hypothetical construct thus far): the outer list would be the list of
commands - as it is now, the inner list would be the list of arguments, and
they'd be properly escaped etc. Some of it could be solved if
COMMAND_EXPAND_LISTS could be somehow applied to normal targets, and thus
to the underlying CMAKE_<LANG>_COMPILE_OBJECT, etc.

Simplifying, thus far I set CMAKE_C_COMPILE_OBJECT to ${CMAKE_COMMAND}
-DV1=<rulevar1> ... -DVn=<rulevarn> -P
${CMAKE_CURRENT_LIST_DIR}/helper.cmake. The helper does the rest. It's
brittle because of poor escaping support. I could also use
C_COMPILER_LAUNCHER with same effect but it couldn't be a cmake script,
since cmake doesn't understand "cmake -D... -P script.cmake -- arbitrary
arguments" (it could without any trouble - it's a small patch; would it be
something worthwhile to add?).

The problem is that I don't really need the overhead of invoking cmake or
another script/process for every compiled/linked output. For both make and
ninja generators, all I'd need is to generate a custom target command that
bypasses the result of the built-in generator. But I also want my
CMakeLists to look familiar and be compatible with additional generators,
thus having a custom "add_my_executable" function wouldn't work, and
overriding "add_executable" to modify some targets, and pass others
directly to "add_executable_" (the undocumented handle to the overridden
function) seems like a big hack.

So, what I'd want to do is to have a function that can be invoked for every
target, before the target is passed to the generator, and that could
inspect the target and modify its properties and override variables in its
scope. In my case, I'd write this function so that each target would get
its own "CMAKE_C_COMPILE_OBJECT" or "CMAKE_C_LINK_EXECUTABLE", fully
expanded, without any generator expressions nor rule variables.

Does cmake already offer any hook like it? A cursory examination of the
source code doesn't seem to indicate so (btw: the code is clear and easy to
follow, so I don't have high hopes...). And if not, would it be a
worthwhile addition? It'd obviate the need for both generator expressions
and rule variables - personally I think that they are half-baked hacks,
with rule variables being even more limited and really only meshing with
gnu-like tools. I imagine that to speed things up, a pre-filter could be
applied - say that "my_function" should be invoked for all executable
targets, for C language and foocc compiler:
"CMAKE_ADD_FILTER(add_executable, my_function, LANGUAGE=c
COMPILER_ID=foocc)". For every invocation of `add_executable`, CMAKE would
check if the filters match, and if so it'd invoke the function, which then
could modify target properties and variables visible to the generator (i.e.
it could regenerate CMAKE_C_COMPILE_OBJECT).

Another approach could be to have said function act like COMPILER_LAUNCHER,
and we'd then have something like:
"CMAKE_ADD_COMPILER_LAUNCHER(my_function, LANGUAGE=c, COMPILER_ID=foocc,
TYPE=executable)"

Cheers, Kuba Ober

[Attachment #5 (text/html)]

<div dir="ltr">Hi, I&#39;m trying to integrate cmake with a set of build tools whose \
command lines look nothing like standard gnu tools.<div><br></div><div>Unfortunately, \
both the generator expressions and the rule variables seem very limited: I have to do \
some custom massaging of the arguments that get passed to the compiler/linker. \
I&#39;ve resorted to using cmake in script mode as a proxy to the compiler and \
linker, passing all the rule variables verbatim, and then having the script call the \
compiler or linker.</div><div><br></div><div>This suffers from problems with escaping \
of spaces, at the very least. It seems like those compilation commands would need \
nested lists (a hypothetical construct thus far): the outer list would be the list of \
commands - as it is now, the inner list would be the list of arguments, and \
they&#39;d be properly escaped etc. Some of it could be solved if \
COMMAND_EXPAND_LISTS could be somehow applied to normal targets, and thus to the \
underlying CMAKE_&lt;LANG&gt;_COMPILE_OBJECT, \
etc.</div><div><br></div><div>Simplifying, thus far I set CMAKE_C_COMPILE_OBJECT to \
${CMAKE_COMMAND} -DV1=&lt;rulevar1&gt; ... -DVn=&lt;rulevarn&gt; -P \
${CMAKE_CURRENT_LIST_DIR}/helper.cmake. The helper does the rest. It&#39;s brittle \
because of poor escaping support. I could also use C_COMPILER_LAUNCHER with same \
effect but it couldn&#39;t be a cmake script, since cmake doesn&#39;t understand \
&quot;cmake -D... -P script.cmake -- arbitrary arguments&quot; (it could without any \
trouble - it&#39;s a small patch; would it be something worthwhile to \
add?).</div><div><br></div><div>The problem is that I don&#39;t really need the \
overhead of invoking cmake or another script/process for every compiled/linked \
output. For both make and ninja generators, all I&#39;d need is to generate a custom \
target command that bypasses the result of the built-in generator. But I also want my \
CMakeLists to look familiar and be compatible with additional generators, thus having \
a custom &quot;add_my_executable&quot; function wouldn&#39;t work, and overriding \
&quot;add_executable&quot; to modify some targets, and pass others directly to \
&quot;add_executable_&quot; (the undocumented handle to the overridden function) \
seems like a big hack.</div><div><br></div><div>So, what I&#39;d want to do is to \
have a function that can be invoked for every target, before the target is passed to \
the generator, and that could inspect the target and modify its properties and \
override variables in its scope. In my case, I&#39;d write this function so that each \
target would get its own &quot;CMAKE_C_COMPILE_OBJECT&quot; or \
&quot;CMAKE_C_LINK_EXECUTABLE&quot;, fully expanded, without any generator \
expressions nor rule variables.</div><div><br></div><div>Does cmake already offer any \
hook like it? A cursory examination of the source code doesn&#39;t seem to indicate \
so (btw: the code is clear and easy to follow, so I don&#39;t have high hopes...). \
And if not, would it be a worthwhile addition? It&#39;d obviate the need for both \
generator expressions and rule variables - personally I think that they are \
half-baked hacks, with rule variables being even more limited and really only meshing \
with gnu-like tools. I imagine that to speed things up, a pre-filter could be applied \
- say that &quot;my_function&quot; should be invoked for all executable targets, for \
C language and foocc compiler: &quot;CMAKE_ADD_FILTER(add_executable, my_function, \
LANGUAGE=c COMPILER_ID=foocc)&quot;. For every invocation of `add_executable`, CMAKE \
would check if the filters match, and if so it&#39;d invoke the function, which then \
could modify target properties and variables visible to the generator (i.e. it could \
regenerate CMAKE_C_COMPILE_OBJECT).</div><div><br></div><div>Another approach could \
be to have said function act like COMPILER_LAUNCHER, and we&#39;d then have something \
like: &quot;CMAKE_ADD_COMPILER_LAUNCHER(my_function, LANGUAGE=c, COMPILER_ID=foocc, \
TYPE=executable)&quot;</div><div><br></div><div>Cheers, Kuba Ober</div></div>



-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: \
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information \
on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at \
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic