[CMake] Is there analog of source command from bash ?

[Alan W. Irwin]

On 2017-05-29 00:36+0300 Konstantin Tokarev wrote:

>
>
> 28.05.2017, 16:58, "Denis Kotov" <redradist at gmail.com>:
>> Hi everyone,
>>
>> I have tried to find solution to the following problem:
>> There is the project with environment variable described in setenv.sh file
>> Old build process looks like:
>> source setenv.sh
>> make release
>>
>> But I want to accomplish this by CMake. But I have realized that CMake does not have analog of source command that's why the following command does not work:
>> execute_process(COMMAND bash -c "source ../setenv")
>
> You can run  source setenv.sh before you run cmake, or in the same shell invocation with command that requires environment

That method just makes those environment variables available at cmake
time and it will require more work to propagate that environment to
the environment used at make time.

@Denis (the OP).  I have an entirely different suggestion. You will
have to experiment (since I have never tried this myself), but
fundamentally you want a command to run at make time before you build
the release target.

I am pretty sure the following idea would implement this without issues:

add_custom_target(update_environment
COMMAND bash -c "source <FULL PATHNAME of setenv file>"
)
add_custom_target(release ALL
COMMAND command1
COMMAND command2
[...]
)
# Make sure the above command is run every time before the release
# target is built
add_dependencies(release update_environment)

N.B. according to
<https://cmake.org/cmake/help/v3.8/command/add_dependencies.html> this
method will only work on top-level targets that you create yourself
with add_executable, add_library, and add_custom_target; and will NOT
work (for good reasons, see below) on CMake-generated high-level
targets such as "test", "all", and "install".  But for example, if you
implement your add_custom_target for the "release" target with the ALL
attribute as above, it will make that custom target a dependency of
the "all" target which itself is (automatically) a dependency of the
"install" target.  So the target dependency chain resulting from
the above idea
would be

install -> all -> release -> update_environment

And similarly for the "test" high-level target.

Which I think is what you want for the dependency chain between the high-level targets
and custom targets.

Good luck, and please let us know the results of your experiments with this
idea.

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________