Chris Quenelle <Chris.Quenelle at sun.com> wrote:
> Can you include references to documentation of these
> specific features in other implementations? I'll be
> happy to file an RFE and ping the dmake engineer.
>
> I've included more specific comments below:
>
>
> Joerg Schilling wrote:
> > Hi,
> >
> > are there any plans to implement modern features in
> > /usr/ccs/bin/make and dmake?
> >
> > 1) SunPro make was the first make program on UNIX to
> > introduce the "include" directive but it still only
> > accepts one file name per include directive. This
> > makes it impossible to implement specific features
> > where the number of included files is not known in the
> > makefile that calls it.
> >
> > Note: if you implement this feature, please add an
> > automatically filled out macro "MAKE_NAME" that contains
> > a value other than "make", "smake" or "gmake".
>
> Are you suggesting that on Solaris when a user runs /usr/ccs/bin/make
> we set MAKE_NAME to a value other than "make"? What value
> should we choose? If this is a version/vendor string, shouldn't
> it include the version number also?
The only porpose for the POSIX defined macro $(MAKE) is to allow to
call exactly the same make program again from within "make".
$(MAKE) contains the last path component of the make program or the
complete path. As Linux e.g. delivers "gmake" as "make", this macro
is unusable for identifying a specific make progam implentation.
On the othe side, the POSIX "make" definition is far away from being
sufficitent to be used as a base for a portable make based build environment.
If you like to support portable software, you can either go the way David Korn
did and write your own portable make program and disallow to use any other
program to compile your software or you may write a portable makefile system
that is able to support more than one make imlementation in case that it
supports ehough features. The latter is the way that I go.
Well I could disallow Sun make as it is non-portable and thus only useful on
one of many platforms. In this case we would _need_ to have "smake" on Solaris
as GNU make has too many bugs is unmaintained (important bugs have not been
fixed during the past 10 years). Note that this would force Sun to first
integrate "smake" on Solaris in order to compile the next cdrtools tarball....
In order to allow the schily make file system to distinct between different
make programs and to supply the right make program specific ruleset, I
introduced the macro "MAKE_NAME" 14 years ago. MAKE_NAME contains the value
"sake" in case of smake and you are free to chose a name for sun make (e.g.
"sunmake" or "dmake"). You just cannot use "smake" or "gmake" as these names
are already in use.
As smake is also implementing "automake" support (note that this is not related
to a software from the FSF that is called automake but does not do what the
name lets you expect), smake defined more make specific macros that help to
implement a portable makefile system like the schily makefile system:
MAKE = smake
MAKEFLAGS = -pr
MAKE_ARCH = i386
MAKE_BRAND =
MAKE_DOMAIN =
MAKE_FLAGS = -pr
MAKE_HOST = unknown
MAKE_HWSERIAL = 342163369
MAKE_ISALIST = amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386
i86
MAKE_LEVEL = 1
MAKE_MACH = i86pc
MAKE_MODEL = i86pc
MAKE_M_ARCH = i86pc
MAKE_NAME = smake
MAKE_OS = sunos
MAKE_OSDEFS = -D__SVR4
MAKE_OSREL = 5.11
MAKE_OSVERSION = snv_117
MAKE_SHELL_FLAG = -ce
MAKE_SHELL_IFLAG = -c
MAKE_VERSION = 1.2a42
as you see, there is also a macro called MAKE_VERSION.
I would need MAKE_NAME in order to detect new sun make versions
that support multiple include file names in a single include directive.
> > 2) POSIX defines a way to forward command line macro=name
> > macro definitions to sub-make programs (make programs
> > called by the current make program) since at least 10
> > years.
> >
> > GNU Make implements this feature since about 15 years and
> > smake implements this feature since 10 years.
> >
> > When whill Sun make implement this feature?
> >
> > Most reasons to patch makefiles from OSS packages will go
> > away in case that command line macro=name definitions
> > are forwarded to sub-makes. You just need to overwrite the
> > values from the top level ake command line.
>
>
> This would certainly be useful in the work I'm doing now.
Good to hear that there are more people who are interested in this feature...
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
