From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Recoskie, Chris
Sent: Tuesday, November 22, 2005
4:20 PM
To: CDT General developers list.
Subject: [cdt-dev] The Shell Game
So I’ve been working for the past week or so on
getting MBS to build files and folders with spaces in them. I’ve
been largely successful thus far, but along the way I ran into some issues which
I thought would be good to bring up.
To summarize, I got everything working nicely for the
GNU toolchains under CygWin. But when I tried using the code for my own,
non-CygWin based toolchains on Windows, things started falling apart, because the
way that commands are passed to the shell under bash doesn’t work on
windows.
For example, on bash, one can escape special
characters in filenames via use of the backslash. Coincidentally, GNU
make also will let you escape spaces in the same manner. Thus, it was
very convenient to say have an OBJS macro that held a list of object files, and
to invoke the linker with said macro as its input. However, on Windows
this broke down, because the Windows shell (cmd.exe) wants the filenames in double
quotes.
As a result, in my own makefile generator I had to
create another macro, OBJS_QUOTED, that would hold a list of the objects
without backslashes escaping the spaces, but rather with quotes surrounding
each entry. For the dependencies in the makefile I use OBJS, but for the
linker invocation I use OBJS_QUOTED. A hardcoded hack, but it works.
I am thinking other people are going to run into this
on Windows, so I’d like to somehow include a proper solution in CDT
rather than resorting to this sort of hackery in my own non-CDT generators.
However, I’m not entirely sure yet the best way to go about this,
as right now we have no way of telling what shell the user is using, regardless
of host OS. I can’t for example assume that the user is using bash
even in a CygWin environment, because they might be using tcsh or some other
bizarre, custom shell of their own creation. A one-size-fits-all solution
for a given platform will not fully cut it. Since there is no universal
way to determine what the user’s shell is (at least not to my knowledge),
it seems like we would need some sort of user configurable setting for shell
properties.
That all being said, my time is a bit scarce right
now given my existing workload. So, right now my current plan of action
is to just leave things as they are. Things in MBS will work as far as I
know for our primary environments that CDT supports out of the box, but those
working on other environments will be somewhat out of luck.
So, I ask:
a)
Does anyone else think that this issue is going to affect
them when using their own toolchains?
b) Does
anyone else think that this might be an issue that affects other parts of CDT?
(Launching/Debugging comes to mind… e.g. will launching a debug session
fail if you try to debug an executable with spaces in the name?)
c)
Do we need to do anything about this right now?
___________________________________________
Chris Recoskie
Texas
Instruments, Toronto
http://eclipse.org/cdt