| Re: [cdt-dev] Variable name of USER:CONFIG environment goes to uppercase |
Jonah
Thanks for the feedback. I fear this won't be a quick fix :-(
I'm not sure the internal uppercasing (based on the OS) is a good
idea. Actually I think it is a bad idea.
For instance if you use the "expand environment variables in
makefile" the environment variables will never hit the OS. In this
use case there is no need to take OS specific rules into account.
What makes this implementation worse is that CDT behaves
differently between OS'es without any reason. Which makes support
a nightmare.
What I think would be a better approach is:
Somewhere deep down in CDT/Eclipse there is code to "Load
environment variables in a console" (what CDT needs to do before
starting the makefile when the option "expand environment
variables in makefile" is disabled)
I think it would be better to have this code warn/error about
"variants of variable names that will not be taken into account by
the OS" (given 15 knots his email I would say warn and allow to
ignore)
Best regards
Jantje
There are a number of cases that it is supposed to workaround, main one that comes to mind is that Path vs PATH on Windows refers to the same environment variable - so it seems that the assumption is on windows the case of the environment variable was not supposed to matter and so normalizing them to all uppercase made sure that Maps in java worked as expected.
There are a few places in the code that do the uppercasing:org.eclipse.cdt.internal.core.envvar.EnvVarCollector.add(IEnvironmentVariable[], IEnvironmentContextInfo, int, ICoreEnvironmentVariableSupplier)org.eclipse.cdt.core.CommandLauncher.parseEnvironment(String[])org.eclipse.cdt.utils.envvar.EnvVarOperationProcessor.normalizeName(String)org.eclipse.cdt.utils.envvar.StorableEnvironment.getNameForMap(String)org.eclipse.cdt.utils.spawner.EnvironmentReader.init()
So either we need to do the uppercasing in more places - or fix all the places so that uses the uppercase workaround and probably change it to a case insensitive keyed map, such as new TreeMap<>(String.CASE_INSENSITIVE_ORDER);
HTH,Jonah
On Fri, 22 May 2020 at 10:30, Jan Baeyens <jan@xxxxxxxxxx> wrote:
_______________________________________________Thanks for the info
I tried this on Linux and indeed no conversion to uppercase on linux. So this is a windows thing.
This means that the conversion to uppercase must be inside an os check.
I'm really curious what this is supposed to workaround.
Best regards
Jantje
Op 22/05/2020 om 2:06 schreef Jonah Graham:
I can look into it further (when at my desk) but I believe the problem is a workaround for environment variables being not case sensitive on windows. What you mention rings a bell, so I'll try to find the bit of code in CDT that is doing it.
Jonah
On Thu., May 21, 2020, 19:29 Jan Baeyens, <jan@xxxxxxxxxx> wrote:
Hi
When I add an environment variable to a managed build CDT project in
project properties->C/C++ build->environment the variable name is
converted to uppercase.
If for instance you add the variable named "test" with the value
"testvalue" it will look as if "test" is not converting to upper case
but when you close the project properties and reopen the variable name
is converted to "TEST".
This is not done for environment variables of origin USER:PREFS
Because CDT is case sensitive when resolving variables this is a bit of
a problem for me and as you can see in this video "strange things happen"
https://youtu.be/Cqs7V46ffvM
So I'm wondering:
1) Is this a known feature?
2) can I turn this uppercasing off?
3) anyone can provide me with some background info?
Background info of what I'm working on right now.
ESP32 is working on a new release and they want to use nested variables. FI:
build.mcu=esp32s2
compiler.cpp.flags.esp32s2=-mlongcalls -ffunction-section
compiler.cpp.flags={compiler.cpp.flags.{build.mcu}}
resulting in
compiler.cpp.flags=-mlongcalls -ffunction-section
Though the comments in CDT code state this should not work it works
fine. But the (timing of the) uppercasing combined with the case
sensitivity causes a problem.
BUILD.MCU=esp32s2
COMPILER.CPP.FLAGS.ESP32S2=-mlongcalls -ffunction-section
COMPILER.CPP.FLAGS={COMPILER.CPP.FLAGS.{BUILD.MCU}}
gives
COMPILER.CPP.FLAGS={COMPILER.CPP.FLAGS.esp32s2}
Which is not resolved.
There is no obvious way to know that the value of BUILD.MCU should be
uppercased. Moreover BUILD.MCU is used in cases where the value can not
be uppercased.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev