halcompile: Add command line arguments to provide compile and link flags

[andypugh]

It is possible to provide extra compiler and linker flags with "option" lines inside a hal component written in the .comp preprocessor format. However for files written in straight C this does not work. This commit adds --extra-compile-args and --extra-link-args as command-line options to halcompile.
See #2204 for more background

Signed-off-by: andypugh andy@bodgesoc.org

[andypugh]

It seems that "readline" was a bad choice of library to use in this test. (This is why the test fails)

+ halcompile --userspace --compile --extra-compile-args=-I/usr/include/readline '--extra-link-args=-lm -lreadline' flags.c
        /tmp/tmpu7ipvcus/flags.c: In function 'main':
        /tmp/tmpu7ipvcus/flags.c:18:5: warning: implicit declaration of function 'rl_ding' [-Wimplicit-function-declaration]

It looks like the library is present, but the function I chose might not be in the version used by CI.

Can anyone suggest a library that is always present in a Linux installation and a function in that library that is also always present.

[jepler]

I applaud your effort to add a test for this, thank you!

It looks like rl_ding is not supported by the readline compatibility layer in libeditreadline, at least on bullseye.

Maybe use rl_initialize instead?

Failing that, you might put a whole self-contained useless library inside the test, including building it into a .a file.

[petterreinholdtsen]

[andypugh]

Can anyone suggest a library that is _always_ present in a Linux installation and a function in that library that is also always present.

What about the math library (-lm) and sin() for the linker test, and basename() from <string.h> with a read-only string and -D_GNU_SOURCE defined for the compile test? See basename(3) for the details on the latter. Both of these should be included with glibc.

…

-- Happy hacking Petter Reinholdtsen

[andypugh]

I think that I am done with this now. The test as-is should work on any valid LinuxCNC installation and now works in the CI system.

[SebKuzminsky]

Looks good to me, just one question about adoc style.

[SebKuzminsky]

Doesn't this line rewrap break the "semantic line breaks" that @smoe et al have been adding?

[smoe]

;) Just checked. Indeed. Had not seen it myself. @andypugh - the auto-translators perform differently at line breaks - not always, but often enough. To avoid that, and to help all the other languages we aim at supporting, I have worked towards individual lines to represent a continuous thought that should be translated as one unit.

[andypugh]

I had seen the "semantic breaks" phrase without actually thinking about what it meant.
Basically lines should wrap at punctuation?

[smoe]

Yes, that is what it most often boils down to. And I have even introduced the one or other comma when I had felt that it would make a sentence easier to understand :)
To explain the problem a bit better, those translators aim at mimicking the overall looks of a text. And newlines are typically reserved for paragraphs in word (where they hence have a meaning). The translators then give their best to have something grammatical before and after the line break - which is not always helpful.
A nice side-effect is that the diffs in git become easier to read.