| RE: [cdt-dev] The Shell Game |
|
I suppose the “using
spaces” problem (as well as using special characters) from the MBS point
of view has two aspects: 1) The most part of the
buildfile generation logic lays upon the buildfile generator, so it is up-to
the buildfile generator to treat spaces and any special characters respectively 2) I said “the MOST”,
because MBS also takes part in the buildfile generation via build macro resolving
functionality. I mean that currently MBS has a build macro resolving API that knows
nothing about how to treat spaces in path macros, so when macros are resolved with
this API while buildfile generation, MBS will not know whether it should leave
spaces intact, or escape them or something else. I don’t think the
first aspect is an MBS bug, since it is up-to the buildfile generator to treat
spaces and escapes correctly, but the second aspect IS an MBS issue and should
be fixed. a)
Does anyone else think that this issue is going to affect
them when using their own toolchains? Speaking in terms of the
two aspects I mentioned previously, I might say, that the aspect #1 is now fixed
for the gnu make, since GnuBuildfileGenerator is now capable of handling
spaces, so no problems should occur for ISVs using gnu make and GnuMakefileGenerator
in their tool-chains. In case one wants to use and integrate some custom
builder, than it would be up to the buildfile generator implementer to handle
spaces and any special characters correctly. BUT the aspect #2 is still
an issue for any tool-chain/builder including gnu make. I’ve raised two additional
bugs related to the space problem handling in MBS core: https://bugs.eclipse.org/bugs/show_bug.cgi?id=117892 https://bugs.eclipse.org/bugs/show_bug.cgi?id=117873 >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?) I think we should
differentiate the different “using spaces” problems. From the MBS
point of view this is an issue related to handling the external builder utility
and the shell logic of treating spaces and special characters. From the launching/debugging
point of view this might be quite another issue not related with the external
builder and a shell used by that builder. The different issues might need
different and unrelated approaches of fixing them. c)
Do we need to do anything about this right now? I think we need to make
MBS core functionality work correctly with spaces, I mean MBS needs to handle
correctly the aspect #2 of the buildfile generation functionality. So all the
issues related to the aspect#2 should be fixed now. Regards, Mikhail From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Recoskie, Chris 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 Software Designer http://eclipse.org/cdt |