Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Library names with spaces fail

Hi all

As someone once told me that I'm probably the person with the most knowledge on GnuMakefileGenerator and as there is a request for a better design I feel I have to provide my 5 cent.

First note that it has been a while since I looked at GnuMakefileGenerator and there was going to be someone who would improve it but I do not know whether this was actually done. So what I say here may be partially outdated.

IMHO the biggest problem with GnuMakefileGenerator is that it converts the internal CDT models to a "string". To convert that "string" to a "string" (read makefile content).

This case is a nice example of the "string to string" conversion. Deep down in the code a string to string conversion is done, but you can't tell what exactly is being converted in what. The -i test Livius proposes is in the current code the most obvious way. But ... will it cause regression... nobody knows.

I think it would be better to work in multiple steps.
The first step: convert the project to a "make oriented model" based on org.eclipse.cdt.managedbuilder.core.buildDefinitions.
The second step: Convert "make oriented model"  to make files

I think that approach would be a lot easier to understand and maintain.

The alternative to simply using path and file classes would be a improvement but would not lead to a good solution.

For anyone feeling to tackle this (like I did) here is a list of things to consider that pop up. 1) As far as I know CDT has multiple "build engines" and I have been told GnuMakefileGenerator is "deprecated". 2) However "bad/outdated" the GnuMakefileGenerator documentation is, I never found documentation on the internal build engine. 3) If you seriously consider rewriting GnuMakefileGenerator find yourself a make expert that can actively participate. Because I don't even know half of the functionality that is in GnuMakefileGenerator. 4) Learn about org.eclipse.cdt.managedbuilder.core.buildDefinitions. It is far more powerful than you would think at first sight. 5) know that the current test scripts drop all newlines making it harder to investigate regression issues.

Best regards


PS I have high regards for the people that created GnuMakefileGenerator. I respect their knowledge, craftsmanship and dedication. I do not want to belittle them in any way. Thanks guys.

Op 13/09/2019 om 7:03 schreef Liviu Ionescu:

On 13 Sep 2019, at 01:53, Liviu Ionescu <ilg@xxxxxxxxxx> wrote:

(I had to override `ensurePathIsGNUMakeTargetRuleCompatibleSyntax()` since `ensureUnquoted()` is static and cannot be overridden).
my explanation was a bit terse, so here is a more detailed one.

for reasons that I do not know, the list of libraries is not passed to the linker directly by expanding the value of the option (of type LIBS), but by passing the $(LIBS) variable and asking make to do the substitution.

in, the USER_OBJS and LIBS variables is initialised by appending the corresponding lists.

the code to do this is in populateObjectsMakefile():

at line 1069, the paths are processed by calling `ensurePathIsGNUMakeTargetRuleCompatibleSyntax()` to keep make happy, which practically means to escape whitespaces.

this function is at line 4363:

and calls the static `ensureUnquoted()` at line 4647. (not static is very fortunate, since statics cannot be overridden in derived classes).

this function strips quotes or double quotes and allow the caller to later escape whitespaces.

for USER_OBJS this is ok, since the value of the option is a list of strings that contains paths, and the result looks like

USER_OBJS := /Users/ilg/My\ Files/WKS\ Projects/xpack-dev-tools.github/arm-none-eabi-gcc-xpack.git/tests/eclipse/arm\ exe\ obj\ spaces/objs\ folder/obj\ file.o

however, for LIBS, the input list contains library names prefixed by -l, with names surrounded by double quotes, but the first one is not at the 0 index, but 2 character later, like

[ -l"arm static lib spaces" ]

thus ensureUnquoted() fails to detect the quotes, and they are not removed from the string.

later on white spaces are escaped, and the current results includes both double quotes and escaped spaces, like:

LIBS := -l"arm\ static\ lib\ spaces"

make is definitely not happy with this syntax, and the link step fails.

the correct line should be:

LIBS := -larm\ static\ lib\ spaces

my temporary hack in ensureUnquoted() is to further look inside the string and detect the -l prefix, but this is not very nice, a more generic solution should be designed, since this function is also called from other places, and other prefixes might be encountered.

hope this helps.


cdt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top