#2949 d_and_c --cmake-arg option

[Mariusz Matuszek]

This is a polite suggestion for a feature rather than a bug report.
Following the recent commit https://sourceforge.net/p/flightgear/fgmeta/ci/b8858a42d1276f484ec4e80cc730383f728b3184/ which added generalized --cmake-arg, could the syntax be further extended to define a CMake option applied globally to all components being built?

A valid use case: -DCMAKE_EXPORT_COMPILE_COMMANDS=YES

for example applied like that:
d_and_c <other options=""> --cmake-option=ALL=-DCMAKE_EXPORT_COMPILE_COMMANDS=YES <components to="" build=""></components></other>

Is it useful enough to be worth the effort?
Shall I try to hack it myself and submit? (may look ugly though.)

[Mariusz Matuszek]

Arrgh! gotta love it, when editor 'knows better' and there is no edit option :(
Anyway, example use was meant to look like
d_and_c "other options" --cmake-option=ALL="some cmake option" "components to build"
Sorry for the noise.

[Florent Rougon]

This makes sense for --cmake-arg. I guess adding ALL options before component-specific ones would be the more useful way.

[Mariusz Matuszek]

Looking at the way you modified the d_and_c I was thinking about adding a phony component ALL to the CMAKE_BASED_COMPONENTS list and then, in every component-specific cmake invocation, like, for example

$extra "${FGFS_CMAKE_ARGS[@]}" \

append

$extra "${ALL_CMAKE_ARGS[@]}" 

So together that part of cmake call would look like this (fgfs in example):

...
              $extra "${FGFS_CMAKE_ARGS[@]}" \
              $extra "${ALL_CMAKE_ARGS[@]}"  \
               ../../flightgear 2>&1 | _logOutput

Would this make sense? It looks like your logic would accept this as-is, or have I missed something?

[Florent Rougon]

I agree about keeping ALL_CMAKE_ARGS as a variable on its own because this would allow us to easily manage the order, which I'd rather see as:

$extra "${ALL_CMAKE_ARGS[@]}" "${FGFS_CMAKE_ARGS[@]}" \ 
../../flightgear 2>&1 | _logOutput

so that FGFS_CMAKE_ARGS can be used to override args from ALL_CMAKE_ARGS.

Also, I think the summary printed by _logCMakeArgsForSelectedComponents() should display ALL_CMAKE_ARGS separately to avoid excessive noise hampering legibility.

Edit: avoiding automatically wrapped lines in the code block.

[Florent Rougon]

Don't worry about sending a patch, I'll implement the feature.

I had another idea “in the pipe” BTW, which is --cmake-args COMPONENT=ARGS where one would be able to easily pass many space-separated options for a given component. Obviously, such options would not be allowed to contain any space themselves, but this is by far the common case for cmake options. Note the name --cmake-args with an s in this case.

[Mariusz Matuszek]

I agree about the order, so component-specific options can override the global ones.

The option to aggregate multiple cmake arguments in a single --cmake-args option seems interesting too, although I personally do not set that many options, so to me the current method (augmented with the 'ALL' option) would be sufficient. Could a comma be used as an argument list separator, instead of a space? I do not recall any cmake arguments using commas off the top of my head..

As for deciding between:

--cmake_arg OPTION

and

--cmake_arg ALL=OPTION

I personally find the latter more self-explanatory, but I have no strong preference and will be happy to have that functionality in either form you implement.
Thank you for accepting my idea.

(edited for spelling)

[Florent Rougon]

I usually don't pass a lot of CMake options, except recently when I built OSG with ASAN support (as well as SG and FG): the command was unwieldy. That is the main motivation behind the future --cmake-args.

Regarding the separator, I prefer space to anything else in this case, because it will make the commands easier to read and is already what d&c uses when it prints the current parameters at the beginning of the log file (function _logCMakeArgsForSelectedComponents()). Besides, the comma is typically used after -Wl when passing linker options to gcc or clang, so it could be needed inside, e.g., -DCMAKE_CXX_FLAGS=....

I'm fine with ALL=OPTION syntax; didn't propose anything else.

Edit: typo

[Florent Rougon]

Actually, there is one small catch about ALL but I don't think it justifies choosing another syntax for --cmake-arg: when used as a non-option argument, ALL causes this to be run:

WHATTOBUILD=( "${WHATTOBUILDALL[@]}" )

and WHATTOBUILDALL is currently defined as

WHATTOBUILDALL=(DATA FGFS OSG SIMGEAR)

However, this is a legacy thing I have always hated. I've never advertised using ALL in this place because I find it very counter-intuitive.

[Florent Rougon]

Should be fixed with commit 5c15be6da5d8.

[Mariusz Matuszek]

Testing...

Edit: command

../fgmeta/download_and_compile.sh -s --cleanup -pn -j8 --cmake-arg ALL=-DCMAKE_EXPORT_COMPILE_COMMANDS=YES FGFS OSG SIMGEAR

worked as expected. All compile_commands.json files were created as requested.

Thank you very much again.

[Florent Rougon]

Glad to hear that. An alternative solution to problems of this kind might lie in CMakeUserPresets.json files, which I only recently became aware of due to JamesT's commits.