[
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
Jantje
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 objects.mk, the USER_OBJS and LIBS variables is initialised by appending the corresponding lists.
the code to do this is in populateObjectsMakefile():
https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/build/org.eclipse.cdt.managedbuilder.core/src/org/eclipse/cdt/managedbuilder/makegen/gnu/GnuMakefileGenerator.java#n1040
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:
https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/build/org.eclipse.cdt.managedbuilder.core/src/org/eclipse/cdt/managedbuilder/makegen/gnu/GnuMakefileGenerator.java#n4636
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
(objects.mk)
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.
Liviu
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
