Bug 113279 - Managed Build Makefile Generation - forward vs back slashes
Summary: Managed Build Makefile Generation - forward vs back slashes
Status: ASSIGNED
Alias: None
Product: CDT
Classification: Tools
Component: cdt-build-managed (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows 2000
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-20 16:17 EDT by John CLA
Modified: 2020-09-04 15:27 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John CLA 2005-10-20 16:17:45 EDT
I'm implementing a custom non-GNU toolchain on Windows using the MBS and I've 
found that my tools do not like forward slashes in path names (i.e. source & 
output file names in the command line).  I found that the MBS and it's 
implementation of the GNU tools always assume that forward slashes should be 
used.

In IManagedBuilderMakefileGenerator and ManagedCommandLineGenerator, there is a 
variable called SEPARATOR which is hard-coded to "/".  Changing it to "\\" 
didn't work 100%.  I found that in the GnuMakefileGenerator.java module, 
SEPARATOR is used in some places, but a forward slash is hard-coded in other 
places: In the code I have (v3.0.0 release from Aug) I found hard-coded forward 
slashes at lines 1799, 1802, 2674, 2676, 2680, and 3367.  There may have been
others that I didn't write down...  That seemed to change all the relative 
paths' forward slashes in the makefiles to backslashes, except in one place - 
output targets in the rules kept their forward slashes, such as:

Src/%.obj: $(ROOT)\Src\%.c
  @echo <blahblahblah>

Src/%.exe: .\Src\%.obj
  @echo <blahblahblah>

The elements of the C_SRCS and OBJS macros contained paths with backslashes as 
desired, but make would spit back an error such as:  "Don't know how to 
make .\Src\ODemo.obj" (since it only knows how to make Src/ODemo.obj).  Other 
than that, it seemed like make didn't mind any of the other backslashes 
throughout the makefiles.

I never found exactly where this last forward slash was inserted - I traced it 
back that the variable "relativePath" GnuMakefileGenerator.java gets the 
forward slashes from ?somewhere? non-obvious.  I suspect that it's where the 
paths get manipulated as "Path" objects, in particular when the "setDevice
(null)" method is called.  I haven't experimented with this yet, but it looks 
like the Path object uses forward or backslashes based on the device
type - if device == "WINDOWS" then it uses backslashes.  I think setting to 
null defaults to forward slashes.

If GNU make *does* accept using backslashes and I'm not just dreaming here, I 
recommend that the GnuMakefileGenerator (and MBS in general) be updated to use 
the SEPARATOR identifier everywhere consistently as well as use the Path 
setDevice() method correctly.  Also, the value of SEPARATOR should be set by an 
option in the tool's GUI or a function call rather than hardcoded, just like 
NEWLINE is:

public final String NEWLINE = System.getProperty("line.separator");

There's also another line of code that I felt was fishy in 
CygwinPathResolver.java at line 84:

result = lines[0].replace(BS,SLASH).split(DELIMITER_WIN);

BS is '\\' and SLASH is '/'.  This code is changing backslashes in path names 
to forward slashes.  If it's using DELIMITER_WIN rather than DELIMITER_UNIX
(implying that the lines are being formatted for Windows), shouldn't it be the 
other way around?

result = lines[0].replace(SLASH,BS).split(DELIMITER_WIN); 

Thanks,
--John
Comment 1 Chris Recoskie CLA 2009-05-12 12:35:27 EDT
The behaviour depends on the version of CygWin you are using.  At the time, the behaviour we currently have worked with CygWin.  It still works in the case of relative paths, but newer vintages of CygWin make choke on absolute windows paths regardless of what type of slash you use.