Thierry Laronde wrote:
> Also, citing SuS/XPG/etc isn't really much use. A lot of systems don't
> comply with them (including Linux, which is our most popular platform;
> Cygwin doesn't either, and I doubt that MacOSX does).
The only Portability specification between OSes is POSIX and the last
one (version 3) is Single Unix Specification. That's why I use it,
discarding all XPG extensions. Every Unix like system should support
POSIX, and since you must start with something, it's better to start
with this (if you are even not guaranteed to have a Bourne shell, sed
and so on...). And I think Cygwin ports at least the POSIX user tools?
The term POSIX refers to a whole family of standards. The most
commonly used are POSIX.1, which describes essential system calls and
library functions (e.g. the ANSI functions, plus those in <unistd.h>,
<fcntl.h> etc), and POSIX.2, which describes essential command-line
utilities (cp, mv, cat etc).
Unfortunately, both of those standards are extremely limited.
Very few packages will compile and/or run on a system which only
provides that which is mandated by those standards. E.g. POSIX.1
doesn't include the BSD sockets API, or anything which requires
"privilege". FWIW, Windows NT is POSIX.1 compliant.
To take a concrete example, look at the SuS specification for the
"echo" command. It doesn't accept any switches, but it does mandate a
number of backslash sequences which aren't supported by either the
echo program from GNU sh-utils or the bash echo built-in command.
In particular, the SuS version doesn't support the -n switch (don't
add a newline), but specifies a backslash sequence for this purpose;
however, neither of the aforementioned GNU implementations support the
backslash sequence. Consequently, we just have to accept that there is
no portable way to echo a string without a trailing newline. Waving a
copy of the SuS at the computer won't help.
If SuS compliance was widespread, we wouldn't need most of the
configure script. However, it isn't widespread; in reality we have to
go according to "common practice".
> > > 2. Provides an "include" feature.
> >
> > that is a SysV compatibility defined at compile time.
> > So this may or may not be present on different BSD flavors.
>
> Without an include feature, we are stuck with the gmake5 approach,
> which is to generate the actual Makefiles via some kind of
> preprocessor which glues together all of the relevant fragments.
> Personally, I think that's going too far.
pmake (make) uses .include.
All the features are here. All I want to say is that indeed there will
be a choice to make, and yes it seems simpler to go the GNU make way...
but perhaps because BSD base systems ensure the portability and are able
to compile packages with gmake, while the other way (Linux based
distributions having the ability to compile with BSD make) is not
guaranteed.
BTW, I'm not suggesting that the "preferred" make program should be
anything other than GNU make. Just to re-iterate my position:
1. Any future build system should be based around GNU make.
2. We should be willing to accept reasonable constraints in order to
accommodate other make utilities which are "sufficiently" compatible
with GNU make.
3. We shouldn't accept drastic constraints in order to accomodate
every possible make utility.
Essentially, point 2 rules out trying to be too "clever" in the kind
of things that the Makefiles (and their include files) do, while point
3 rules out accomodating "weird" make programs (e.g. csh-based makes,
NMAKE etc).
--
Glynn Clements <glynn.clements@virgin.net>
