When I try to push to gerrit I get "no authorisation"; which
seems fine to me
When I try to commit I get
Not sure what to do now.
Best regards
Jantje
Op 28/05/2020 om 15:10 schreef Jan
Baeyens:
Jonah
Though it is not my preferred solution, I'll try to get it to
work like windows does with the capitalisation in place.
Jantje
Op 27/05/2020 om 16:07 schreef
Jonah Graham:
Hi Jantje,
Your idea sounds on the correct track - but you can't
remove, only change Windows specific code. In particular
the thing most likely to break if you start changing case
sensitivity of environment variables is Path. So the more
complete/correct solution is to implement the same case
insensitivity in CDT that Windows does in practice, but as
Windows does, preserve the incoming case. The preserving
the case is the new part to this equation.
The final thing to keep in mind is that other tools on
Windows follow the same conventions that CDT does, in
particular msys also uppercases all environment variables,
so you may find that you end up with other places that
environment variables have case changed, even if you
carefully preserve them in CDT. Some tools (like mingw
make I believe) uppercase the PATH environment variable,
but preserve case for other variables.
On Sun, 24 May 2020 at
19:00, Jan Baeyens <jan@xxxxxxxxxx> wrote:
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.