Re: [cedet-semantic] Make with Windows_NT cmd.exe and other things

> 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.

Thread view

> From: stephen_leake@...
> To: cedet-semantic@...
> Date: Tue, 23 Oct 2012 17:29:15 -0400
> Subject: Re: [cedet-semantic] Make with Windows_NT cmd.exe and other things
>
> vincent.belaiche@... (Vincent Belaïche) writes:
>
> > OK, I know that somebody is going to say "anyway you can build with
> > cedet-build.el". But the discussion point is not just to build CEDET,
> > but to build any project in a portably, and about this I am still in the
> > opinion that if GNUMake had more shell-like builtins (to do things like
> > cp, mkdir, rmdir, rm, and find ... -exec) that would make this easier.
>
> Gnu Make and Gnu Bash run everywhere you need them; that is the most
> portable solution.
>
That was also my opinion, but you get into troubles when the makefile
contains some command that do not understand the file path syntax of the
bash port to MSWindows.
This is where from I started: CEDET makefiles use emacs to byte-compile
EMACS lisp code, if you use an MS-Windows port of emacs and the MSYS bash
then you are in trouble when EMACS gets file path from MSYS GNU make.
This can be circumvented by some tricks which I proposed. But when I did
that I was replied to that this is not the correct way to proceed, and
on MSWindows one should you mingw make, not msys make, and do with cmd.exe
rather than bash.
> --
> -- Stephe
>
Vincent.

> From: vincent.belaiche@...
> To: cedet-semantic@...
> Date: Wed, 24 Oct 2012 22:43:19 +0200
> CC: vincent.belaiche@...
> Subject: Re: [cedet-semantic] Make with Windows_NT cmd.exe and other things
>
> > From: stephen_leake@...
> > To: cedet-semantic@...
> > Date: Tue, 23 Oct 2012 17:29:15 -0400
> > Subject: Re: [cedet-semantic] Make with Windows_NT cmd.exe and other things
> >
[...]
> >
> > Gnu Make and Gnu Bash run everywhere you need them; that is the most
> > portable solution.
> >
>
> That was also my opinion, but you get into troubles when the makefile
> contains some command that do not understand the file path syntax of the
> bash port to MSWindows.
>
> This is where from I started: CEDET makefiles use emacs to byte-compile
> EMACS lisp code, if you use an MS-Windows port of emacs and the MSYS bash
> then you are in trouble when EMACS gets file path from MSYS GNU make.
>
> This can be circumvented by some tricks which I proposed. But when I did
> that I was replied to that this is not the correct way to proceed, and
> on MSWindows one should you mingw make, not msys make, and do with cmd.exe
> rather than bash.
>
> > --
> > -- Stephe
> >
>
> Vincent.
>
And just to re-state myself the crux of the problem is that GNUMake
needs some shell calls for a number of operations (mkdir, rm, cp, find
... -exec ...) that are commonly found in makefiles. This is what often
creates a dependence of GNUMake on bash. Other build system like ant
have their own builtins to do that which makes it easier to write build
scripts that portable.
The reason why I am so much dwelling on this topic is that every time
which I want to build for MSWindows an open source SW --- not only CEDET
;-) --- I fall into that sort of issue. I don't know if this is the
appropriate forum to put these ideas forward, but after all EDE is part
of CEDET and is supposed to provide build ability...
There are a number of way where this issue could be worked
around for building in MSWindows, here follows a summary:
- use GNUMake + bash + coreutils of Cygwin
- pro: perfect match with Linux
- con: you aren't using a native environment which means performance
and disk space impact
- use GNUMake + bash + coreutils of MSYS
- pro: native and lightweight
- con: problems as soon as one of the program called by Make is not an
MSYS application, e.g. emacs being called for byte-compilation
--- this is the problem with CEDET GNUMaking
- That case could be circumvented is there existed some patched
version of emacs that would be an MSYS application, or that
would behave like an MSYS application when environment
variables OSTYPE and MSYSTEM are set accordingly
- another way to circumvent this is to go through some GNUMake
macros playing tricks to generate all paths to Win32 EMACS in
a way that EMACS can understand them --- this was my first
proposal to port CEDET Makefile to MSWindows
- use GNUMake of Mingw32 + cmd.exe + coreutils of GNUWin32 (recommended
way to build EMACS)
- pro: native and lightweight
- con: the Makefile must be explicitly written to be compatible with
both bash and cmd.exe which have different syntaxes, this can
be circumvented in a number of ways
- put whatever is shell specific into GNUMake macros that a
defined conditionally to the shell --- this was my second
proposal to port CEDET Makefile to MSWindows
- con: loss of readability of the Makefile
- write different makefiles for *nixy and MSWindows
- con: more maintenance work
- use a system that generates Makefile specific to the target platform &
associated tooling
- this is what perl Makefile module does
- this is what EDE can do, but currently it does not generate
Makefiles for MSWindows
- I think that there are also similar things in the EMACS build where
some of the makefiles are generated after some M4 preprocessing
- use a separate ad hoc script to build on MSWindows
- this is what CEDET cedet-build.el does
- HEVEA use a similar trick: it has a batch file that is used to build
on MSWindows, this batch file is generated by parsing the log of a
Linux build.
- con: You re-invent what GNUMake does perfectly, that is to say,
most of the time you do a re-build all and lose all the
partial build and parallelization that GNUMake can do.
- con: Well, you have to find some way to generate this ad hoc
script, this is not a standard procedure, you have to invent
something specific for each project.
- use a build system that is more platform independent that GNUMake, the
only candidate that come to my mind is ant. code::block seems less
flexible but could be another one.
- last but not least, maybe some day GNUMake people add the missing few
builtins that would make GNUMake less dependent on the shell.
VBR,
Vincent.

> From: stephen_leake@...
> To: vincent.belaiche@...
> Date: Thu, 25 Oct 2012 15:21:54 -0400
> CC: cedet-semantic@...
> Subject: Re: [cedet-semantic] Make with Windows_NT cmd.exe and other things
>
[...]
>
> > 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.
Are there any port of bash to MSWindows that would use semi colon for
the path name list in the PATH environment variable ?
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.
Vincent?

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.
> 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.
> 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. Certainly bash syntax is far more
portable than cmd.exe syntax!
--
-- Stephe

> 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.

vincent.belaiche@... (Vincent Belaïche) writes:
>> Gnu Make and Gnu Bash run everywhere you need them; that is the most
>> portable solution.
>>
>
> That was also my opinion, but you get into troubles when the makefile
> contains some command that do not understand the file path syntax of the
> bash port to MSWindows.
>
> This is where from I started: CEDET makefiles use emacs to byte-compile
> EMACS lisp code, if you use an MS-Windows port of emacs and the MSYS bash
> then you are in trouble when EMACS gets file path from MSYS GNU make.
MSYS is _not_ intended for this use; it is intended for compiling
autotool builds only.
Use Mingw make and bash; those are compatible with all other Gnu make
and bash.
> This can be circumvented by some tricks which I proposed. But when I did
> that I was replied to that this is not the correct way to proceed, and
> on MSWindows one should you mingw make, not msys make,
Yes.
> and do with cmd.exe rather than bash.
I don't see why.
--
-- Stephe

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details