> From: stephen_leake@...
> To: vincent.b.1@...
> CC: cedet-semantic@...
> Subject: Re: [cedet-semantic] Make with Windows_NT cmd.exe and other things
> Date: Thu, 25 Oct 2012 18:10:07 -0400
>
> Vincent Belaïche <vincent.b.1@...> writes:
>
> >> > and do with cmd.exe rather than bash.
> >>
> >> I don't see why.
> >>
> >
> > [...]
> >
> > One reason is because the handling of the `:' colon character by bash,
> > which is used by MSWindows for drive letter.
>
> It's been a _very_ long time since I had to build anything on a disk
> drive other than c:. So I suspect this is a non-issue.
>
I don't think so, the implications are quite deep: this is the reason
why msys replaces `c:' by `/c', which makes it non understandable by non
MSYS applications.
> > Are there any port of bash to MSWindows that would use semi colon for
> > the path name list in the PATH environment variable ?
>
> I doubt it.
>
> But the other alternative is Cygwin. That works quite nicely for me, but
> it seems to be a religous issue with some people.
>
Yes, I think that this is a kind of "religious" issue: if your starting
point is that you don't want people to be jailed inside MSWindows, then
you have to think that the very first step is to use platform
independent applications, where your data and your documents do not
depend on the OS. So to do that, it must be easy to build the same
application either for a *nixy system or for MSWindows.
Now with *nixy system it is most of the time the same configure + make
story, while for MSWindows it is every time a different trick. Here are
three examples illustrating my point:
- EMACS build: use cmd.exe configure.bat + mingw32-make based on cmd.exe
- CEDET build: use cedet-build function
- HEVEA build: use some batch file that is derived from a linux
re-build-all by some text parse
When think about the root cause why it is this way, one of them is that
most GNU application rely o GNU-Make for the build, and GNUMake has some
limitations that means that people commonly do bash specific statements
in the Make statements.
Actually, because GNUMake relies on recipe that are command lines, it is
unavoidable that it is dependent on the underlying shell command line
syntax --- e.g. how quotes are handled it different between bash and
cmd. And for one thing this is one of the strength of GNUMake that it
does not try to re-invent the shell. So when one knows some shell
commands, he/she can easily write a makefile, whereas writing an ant
build script would require more effort.
But then if you want to make the makefile multi-platform you have to
write it in a way that uses only indirectly the shell. This is what I
tried and proposed. That kind of job could be greatly simplified if
GNUMake had more shell-like built-in, but still it is not to difficult
to do.
> > Anyway the piece of advice to use cmd.exe when in MSWindows was from Eli
> > Zaretskii --- probably that concerned only building EMACS, but I
> > interpreted it as some more general thought.
>
> I'm guessing that's emacs-only.
Only Eli can say the scope of his statement.
> Certainly bash syntax is far more portable than cmd.exe syntax!
>
I fully agree, not only it is more portable, but also it is quite easier
notably for the following:
- quote handling, where echo is a special case in cmd.exe, and where
cmd.exe does not have the ' quotes
- variable expansion,
- cmd uses %, which means it is hard to expand a variable the name of
which is also the result of a variable expansion --- anyway bash has
arrays which makes that kind of tricks less useful.
- cmd is funny with statements like for, where the variables are
expanded in the loop body before it is entered, this is why you need
those double %% in the loop body, and this is why the following code
for /L %%i in (1 ,3 ,10) do (
set /A a=%%i + 1
echo a is worth %a%)
will echo
a is worth 11
a is worth 11
a is worth 11
a is worth 11
rather than
a is worth 2
a is worth 5
a is worth 8
a is worth 11
to do that sort of thing you need to call a gosub, which makes it
impossible to do on-liner statements, and force you to create some
separate batch file
> --
> -- Stephe
Anyway, my objective was not to build CEDET using makefile, but it just
happened that my JDEE was broken due to a too old CEDET, and I had
forgotten how I had built my CEDET.
That made me realize that one of the reason --- if not the main reason
--- why people on MSWindows have so little adoption of free software, is
that installation is so complex --- even for a geek --- when the target
is MSWindows. When I write "so complex", I do not mean "so complex for a
particular application". But I mean that it depends so much of the
application that every time you have to seek again what is the trick
that has been used for MSWindows.
Vincent.
|