User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
Jonah
I need to decide on working around this issue or fixing it in CDT
lets say in a couple of weeks. As I know it takes time to take
difficult decisions I would like to point this out now so you can
think about this before the decision needs to be taken.
For me working around this issue in Sloeber is going to be
painful and so is fixing this in CDT. The fix in CDT will benefit
more people so has my preference.
For the second I'll need your approval for the solution. I see 3
ways to fix this in CDT
3) 1+alert the user when a new environment variable is created
that is only case different from a existing one.
My preference goes to 3 (though I might not be able to do this
due to lack of swt skills) because the current implementation is
..... crap.
FI in sloeber I use
${JANTJE.MAKE_LOCATION}make
in project properties->C/C++build build command
This expands to
C:\\sloeber\\arduinoPlugin\\tools\\make\\make
If I change this to (using c instead of C)
${JANTJE.MAKE_LOcATION}make
This expands to
make
In other words the current solution is still case sensitive.
The only thing that is "fixed" right now is that when you have
2 environment variables in CDT that are only different at the
level of casing one of these variables will not be silently
overwritten by the other at the OS level but silently
overwritten at the CDT level. (!!!read this again!!!)
This at the cost of enforcing all variable name usages in CDT
to be uppercase.
For teams that share their settings: when the project is shared
between multiple OS(of which one is windows) these rules will
apply to all OS.
And this is where option 3 comes in. If a user creates a
environment variable that is only case different from a existing
variable we could warn them that windows os doesn't differentiate
between them and therefore using this variable name may not be a
good idea.
As I really would like this seen fixed in CDT. I hope you have
some time to think this over.
Best regards
Jantje
PS Reality has proven me wrong so many times before; so I'm
really reluctant to say this.
IMHO there will not be regression issues because
1)in the current implementation everything in CDT is case
sensitive and everything remains case sensitive.
2)in the current implementation everything in windows is case
insensitive and everything remains case insensitive.
3)Currently CDT users on windows will only have all uppercase
environment variables.
4) When they reference these in CDT these references must match
case and thus be upper case and that will remain so.
5) and when they use them in windows the case is and will be
unimportant.
So nothing changes to the existing cases. We only extent the
number of possible cases which should not lead to regression.
Op 22/05/2020 om 19:58 schreef Jan
Baeyens:
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
Op 22/05/2020 om 17:49 schreef Jonah
Graham:
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:
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);
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"
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.
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.