[CMake] Call function from name and list, including empty elements?

Craig Scott craig.scott at crascit.com
Thu Oct 4 08:55:56 EDT 2018


Sorry for the delay, a few more replies to your latest questions embedded
below.


On Sun, Sep 30, 2018 at 6:06 PM Jan Wielemaker <jan at swi-prolog.org> wrote:

>
> >     I've come as far as understanding:
> >
> >         - The generator creates cmake_install.cmake
> >         - make/ninja/... install calls cmake -P cmake_install.cmake
> >         - This calls file(INSTALL ....)
> >
> >     So, I thought I can
> >
> >         - Add a file cmake_ln_install.cmake that
> >           - redefines file()
> >           - includes cmake_install.cmake
> >
> >
> > You will likely find it more convenient to use install(CODE)
> > <https://cmake.org/cmake/help/latest/command/install.html#code> or
> > install(SCRIPT)
> > <https://cmake.org/cmake/help/latest/command/install.html#script> to
> > define commands to add to the install process rather than trying to work
> > with cmake_install.cmake directly. Those two forms of the install()
> > command are the recommended way to get your own code into the
> > cmake_install.cmake file that CMake generates. At the moment, you would
> > need to use execute_process() to invoke cmake -E create_symlink to
> > create the actual link within that code or script (see further below for
> > state of the file() command for this).
>
> Ok. I'm already using some install(CODE) for post-copy installation
> steps. I find the interface rather clumsy as you typically need to call
> external processes and need to get the quotes right :( Good news is that
> cmake allows you to hide all this stuff behind a function. So, I guess
> your proposal would be to define a function that abstracts away over
> installing the Prolog (data) files and uses one of the above if some
> option is selected and the usual install(FILES ...) otherwise?
>

I'm not really making a proposal, but if you can see a robust way to hide
away the clumsiness in your particular situation, then go for it.




>
> > I have a follow-up "part 2" article to the above one I linked, but it is
> > still in preparation. It discusses other problems with trying to forward
> > arguments using ARGN or ARGV, but some of the observations you've made
> > here and in the linked stackoverflow article may also be relevant. If I
> > get time, I'll try to see if I can incorporate some of the observations
> > and behaviors you've raised.
>
> Is it a plan to have something that reliably does forward arguments?
> I needed that in some of my internal abstractions (between my own
> functions) and I've seen quite a few questions on how to do that.
> For example,
>
>      call_function(name a1 a2 ... list)
>
> where list is a variable name rather than an expanded variable, i.e.,
> the last argument is always a variable _name_?
>

I'm not aware of any active work going on to more robustly support argument
forwarding.




> P.s.    Examining the source a bit further, it seems that installing
>         a file that is in fact a symlink will create a symlink.  Would
>         a simple way around be to create a secondary tree next to the
>          source tree that copies the directory structure and symlinks
>          all the files work?
>

Erm, maybe try it and see, I don't know off the top of my head. ;)


>
> P.s.    Migrating from autoconf/make to cmake was a lot of work
>         (about 2 weeks for converting 45 Makefile.in and 37
>         configure.ac files), but make the build specification
>          a lot easier to follow and much shorter.  Especially
>         using the ninja backend, building is quite a bit
>          faster as well.
>

Just wait until you get a chance to add ccache into the mix too. :D

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20181004/d641d4f8/attachment.html>


More information about the CMake mailing list