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