|
A standard make tool should support quoting. So IMO, if there are blanks
in build rules (no matter if file or logical names), they should be quoted by
the instance generating them, that is, the build system. Other than that, the
whole IDE could restrict project/file paths/names to not contain blanks in
general...
In our Eclipse-based IDE, we support folder and file names with blanks
(which of course makes much less sense anyway), but (due to some other reasons)
no projects or workspaces (I doubt a lot of users will use blanks
anyway).
Just my 2 cents,
Walter
For a standard make tool this behavior is "correct". It
is a known issue that the syntactic requirements for "make rules" do not
comply with the rules for filename and path names on the host operating
system. Make uses (white-)spaces as list separator.
In
all: My C Project
the standard make syntax parser recognizes a rule that
describes that the target "all" depends on three sub-targets, namely "My",
"C", and "Project"
A similar problems occurs when windows style absolute
path names are involved in rules:
C:\temp\out.o: C:\temp\in1.c
C:\temp\in2.c
Here the colon is the problem, since make uses it to
separate the target from its dependencies. A dumb parser will recognize the
first colon as separator and thus identify "C" as target and "\temp\out.o" as
first dependency and then run into trouble with the next
colon.....
We have this problem when using
Cygwin.
Nils
I don’t know whether this is a bug
or not but if a C project name contains spaces, the generated makefile
produces something like:
# All
Target
all: My C
Project
The linker is then invoked 3
times. Is this right?
This is on latest
HEAD.
Mike
W
| 