| RE: [cdt-dev] The Shell Game |
|
Spaces in the path to the workspace already worked on CDT 2.0+. The paths for any IResources were already project relative in MBS, so they didn’t cause problems so long as they themselves didn’t contain spaces. You were even already able to have spaces in the name of your project (the artifact naming algorithm converted the spaces to underscores).
Unfortunately for us, our users have been continually frustrated with the lack of support for spaces, to the point where we can’t just ignore the issue (otherwise I wouldn’t already be working to support it). Some of them can work around it, others more or less can’t because of legacy reasons (e.g. large existing codebase they don’t want to change) or corporate policy (“Thou shalt name thy project like X, and thy files like Y, and place everything under directory Z”, etc.).
Full paths will never fully go away due to the linked resources issue. You could in theory create a relative path if the file resides on the same drive as the project, but even that is far from foolproof if you want the project to be portable.
Anyway, don’t get me wrong. I’m working around things on my own end. Just giving everyone else a chance to speak up if they’re going to find this a killer.
___________________________________________
Chris Recoskie Software Designer Texas Instruments, Toronto http://eclipse.org/cdt
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Well, while I think solving this helps make us a first class IDE on Windows, I don’t think it is overly necessary. Visual Studio works just fine with spaces in file names. In fact the default home for projects is in “My Documents”. But everyone else who does C/C++ development that I know of strongly recommends that you don’t use spaces in file names.
One question I had, what happens if we have spaces in the path to the workspace, but then not in any of the IResources. Does that work? Can we avoid problems in that situation by only using relative paths wherever we can?
Cheers, Doug
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 Texas Instruments, Toronto http://eclipse.org/cdt
|