Thread: Re: [cedet-semantic] Make with Windows_NT cmd.exe and other things
Brought to you by:
zappo
From: <vin...@gm...> - 2012-10-24 20:43:30
|
> From: ste...@st... > To: ced...@li... > Date: Tue, 23 Oct 2012 17:29:15 -0400 > Subject: Re: [cedet-semantic] Make with Windows_NT cmd.exe and other things > > vin...@gm... (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 B. <vin...@ho...> - 2012-10-25 05:08:46
|
> From: vin...@gm... > To: ced...@li... > Date: Wed, 24 Oct 2012 22:43:19 +0200 > CC: vin...@gm... > Subject: Re: [cedet-semantic] Make with Windows_NT cmd.exe and other things > > > From: ste...@st... > > To: ced...@li... > > 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: Vincent B. <vin...@ho...> - 2012-10-25 20:23:40
|
> From: ste...@st... > To: vin...@gm... > Date: Thu, 25 Oct 2012 15:21:54 -0400 > CC: ced...@li... > 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? |
From: Stephen L. <ste...@st...> - 2012-10-25 22:10:16
|
Vincent Belaïche <vin...@ho...> 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: Vincent B. <vin...@ho...> - 2012-10-25 20:25:03
|
> From: de...@ra... > To: vin...@gm... > Date: Thu, 25 Oct 2012 17:40:36 +0200 > CC: ced...@li... > Subject: Re: [cedet-semantic] Make with Windows_NT cmd.exe and other things > [...] > > Wrong URL. See > > http://cedet.sourceforge.net/bzr-repo.shtml > [...] Thanks, I totally missed it... bzr is very powerful and there are many ways to use it. Vincent |
From: Vincent B. <vin...@ho...> - 2012-10-27 06:02:28
|
> From: ste...@st... > To: vin...@ho... > CC: ced...@li... > 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 <vin...@ho...> 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. |
From: Stephen L. <ste...@st...> - 2012-10-25 19:22:03
|
vin...@gm... (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 |