Re: [cedet-semantic] Make with Windows_NT cmd.exe and other things
Brought to you by:
zappo
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. |