-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am posting this to our arch list; if I'm wrong, we can move this. I want to
argue for some changes to our great make(1) tool.

I've long been a fan of make, and in particular, FreeBSD's make. In my own
career, I've often had to do more custom creation of Makefiles, and while there
are some folks here who definitely DO know our make better, I think I can
honestly say I know it pretty well. In creating tools for customers, I've
often been forced, unwillingly, to go to the GNU make tool. The reason is just
one of compatibility. There are several different reasons for this, which I
want to list:

1) while the GNU make has the -v to allow one to both identify the tool and the
version, FreeBSD's make has no such facility, that I'm aware of. You can't test
& capture the type of make here, except by the rather inadequate trapping of
getting no response at all.

2) while some parts of our make don't advertise it, they can be made compatible
to the gmake's tools. "include" is a good example (the FreeBSD "include" docs
claim that it only works as ".include", but that's a prevarication (and a very
good thing it is). What I'd like to argue for is that some things like "if"
have their compatibility with gmake enhanced. No, don't make it a mirror image,
just make it possible for a programmer to craft a limited set of tests that will
work in both places.

If you give programmers the ability to detect what make they're in, the ability
to craft a limited set of compatible tests, and also the other side (endif
stuff) then everything else for portability can be done by using those limits.

If something like this were done, then it allows a programmer, finally, to write
a REALLY portable makefile. It would still allow one to make use of all of
make(1)'s great command set, but not to kill it's use in a gmake-only system.

OK, that'st the major argument. I'm going to ask for one thing here, but it's
truly extra, just my own bias's showing thru. I wish that a fair number of the
changes that have gone into make be taken back. I'm not talking about those
that enhanced it's operation, I'm talking about all of the changes that, while
trying to increase the elegance of the code, have really destroyed it's porrting
portability, in a major way. Make used to depend on a smaller set of libraries,
and those libraries were largely those available on other systems, so the task
for a programmer, to port our make(1) to a different platform wasn't all that
hard to do. Nowadays, with a great number of the changes having been crafted to
change dependencies to FreeBSD-only tools, it's a real bear to port it.

The code involved is nearly all very, very portable; it's the way that the
libraries have been constituted that makes porting this a really bad job. If
someone would make up a libmake.so.1, which in itself could be make really
portable, that would also go a great long way to improving the popularity of our
make(1). I'm NOT asking to roll back any of the distinct improvements that have
gone in, only the changes that ruined it's porting-ability (yea, that's
portabilty, I just wanted to really point that out again).

OK, if someone were to come up with swuch a set of changes, would they be dead
on arrival? I know that no one gets prior approval for FreeBSD (I completely
agree with that), just didn't want to be totally at odds with everyone, if I'm
the only one who sees it this way.

Thanks for your time.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAki1iEUACgkQz62J6PPcoOkniQCfWg+wlDrQ6r C+g2jGip12Q1VF
koQAnRv4Sjs6xnebEEipKcGF1lXYZmRP
=6ike
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

The only excuse I have for top posting here is that I agree
with the entirety of this email.

-Alfred

* Chuck Robey [080827 10:28] wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I am posting this to our arch list; if I'm wrong, we can move this. I want to
> argue for some changes to our great make(1) tool.
>
> I've long been a fan of make, and in particular, FreeBSD's make. In my own
> career, I've often had to do more custom creation of Makefiles, and while there
> are some folks here who definitely DO know our make better, I think I can
> honestly say I know it pretty well. In creating tools for customers, I've
> often been forced, unwillingly, to go to the GNU make tool. The reason is just
> one of compatibility. There are several different reasons for this, which I
> want to list:
>
> 1) while the GNU make has the -v to allow one to both identify the tool and the
> version, FreeBSD's make has no such facility, that I'm aware of. You can't test
> & capture the type of make here, except by the rather inadequate trapping of
> getting no response at all.
>
> 2) while some parts of our make don't advertise it, they can be made compatible
> to the gmake's tools. "include" is a good example (the FreeBSD "include" docs
> claim that it only works as ".include", but that's a prevarication (and a very
> good thing it is). What I'd like to argue for is that some things like "if"
> have their compatibility with gmake enhanced. No, don't make it a mirror image,
> just make it possible for a programmer to craft a limited set of tests that will
> work in both places.
>
> If you give programmers the ability to detect what make they're in, the ability
> to craft a limited set of compatible tests, and also the other side (endif
> stuff) then everything else for portability can be done by using those limits.
>
> If something like this were done, then it allows a programmer, finally, to write
> a REALLY portable makefile. It would still allow one to make use of all of
> make(1)'s great command set, but not to kill it's use in a gmake-only system.
>
> OK, that'st the major argument. I'm going to ask for one thing here, but it's
> truly extra, just my own bias's showing thru. I wish that a fair number of the
> changes that have gone into make be taken back. I'm not talking about those
> that enhanced it's operation, I'm talking about all of the changes that, while
> trying to increase the elegance of the code, have really destroyed it's porrting
> portability, in a major way. Make used to depend on a smaller set of libraries,
> and those libraries were largely those available on other systems, so the task
> for a programmer, to port our make(1) to a different platform wasn't all that
> hard to do. Nowadays, with a great number of the changes having been crafted to
> change dependencies to FreeBSD-only tools, it's a real bear to port it.
>
> The code involved is nearly all very, very portable; it's the way that the
> libraries have been constituted that makes porting this a really bad job. If
> someone would make up a libmake.so.1, which in itself could be make really
> portable, that would also go a great long way to improving the popularity of our
> make(1). I'm NOT asking to roll back any of the distinct improvements that have
> gone in, only the changes that ruined it's porting-ability (yea, that's
> portabilty, I just wanted to really point that out again).
>
> OK, if someone were to come up with swuch a set of changes, would they be dead
> on arrival? I know that no one gets prior approval for FreeBSD (I completely
> agree with that), just didn't want to be totally at odds with everyone, if I'm
> the only one who sees it this way.
>
> Thanks for your time.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (FreeBSD)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAki1iEUACgkQz62J6PPcoOkniQCfWg+wlDrQ6r C+g2jGip12Q1VF
> koQAnRv4Sjs6xnebEEipKcGF1lXYZmRP
> =6ike
> -----END PGP SIGNATURE-----
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

--
- Alfred Perlstein
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

On Wed, 27 Aug 2008 13:00:54 -0400, Chuck Robey wrote:
> I am posting this to our arch list; if I'm wrong, we can move this. I
> want to argue for some changes to our great make(1) tool.
>
> I've long been a fan of make, and in particular, FreeBSD's make. In
> my own career, I've often had to do more custom creation of Makefiles,
> and while there are some folks here who definitely DO know our make
> better, I think I can honestly say I know it pretty well. In creating
> tools for customers, I've often been forced, unwillingly, to go to the
> GNU make tool. The reason is just one of compatibility. There are
> several different reasons for this, which I want to list:

I can certainly feel the `pain' of reluctantly choosing GNU make, or
even of going the automake/autoconf/libtool way. I have written a fair
amount of build glue myself too, and I know that I'd love to have BSD
make in other systems too.

Since the topic of (re)using FreeBSD make on non-BSD platforms seems to
pop up more or less every 4-6 months the last year, I've started at
least two attempts at porting 'FreeBSD make' to non BSD systems. The
last attempt was aiming for a 'clean' set of minimal changes to the
source of make. And it's done. At least the *binary* of make builds
and tries to pull bsd.*.mk files on Linux and Solaris 10 here.

The actual *source* code changes needed to build a BSD-make executable
on Linux are pretty 'small':

keramida@mithra:/home/keramida/tools$ uname -a
Linux mithra 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008 i686 GNU/Linux
keramida@mithra:/home/keramida/tools$ hg short -r1
1:664527963082 | 2008-07-25 16:47 +0300 | keramida: Import FreeBSD make-20080724 snapshot (svn 180782)

The diff from the first snapshot import of FreeBSD make touches only a
few files:

keramida@mithra:/home/keramida/tools$ hg diff -r 1:tip bin/make | diffstat -p1
bin/make/Makefile | 8 +++++-
bin/make/compat.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++ +
bin/make/compat.h | 36 +++++++++++++++++++++++++++
bin/make/job.c | 8 +++++-
bin/make/main.c | 17 ++++++++++++
bin/make/pathnames.h | 2 -
6 files changed, 135 insertions(+), 3 deletions(-)
keramida@mithra:/home/keramida/tools$

Now I'm looking for some spare time to clean-up the changes a bit and
integrate them in `http://hg.hellug.gr/bmake/gker/'.

The tricky part is, however, that a lot of the functionality of make(1)
depends on the `share/mk/bsd.*.mk' files. I have finished writing the
automake glue that installs these in `$prefix/share/mk' but now I am
kind of stuck while thinking about a good way to make the bsd.*.mk files
actually usable on, say, FreeBSD, Linux and Solaris.

> 1) while the GNU make has the -v to allow one to both identify the
> tool and the version, FreeBSD's make has no such facility, that I'm
> aware of. You can't test & capture the type of make here, except by
> the rather inadequate trapping of getting no response at all.

Both -v and -V are taken, and I don't really like the idea of adding
long options to make(1). Maybe we can partially ``hijack'' the -v
option to also display a verbose version string, i.e.:

% make -v
FreeBSD make (version 5200408120)
make: no target to make.
%

It's probably ok to print a version number when 'being extra verbose'

> OK, that'st the major argument. I'm going to ask for one thing here,
> but it's truly extra, just my own bias's showing thru. I wish that a
> fair number of the changes that have gone into make be taken back.
> I'm not talking about those that enhanced it's operation, I'm talking
> about all of the changes that, while trying to increase the elegance
> of the code, have really destroyed it's porrting portability, in a
> major way. Make used to depend on a smaller set of libraries, and
> those libraries were largely those available on other systems, so the
> task for a programmer, to port our make(1) to a different platform
> wasn't all that hard to do. Nowadays, with a great number of the
> changes having been crafted to change dependencies to FreeBSD-only
> tools, it's a real bear to port it.

make(1) is actually pretty 'easy' to compile on, say, Linux, as I wrote
above. The only bits that are missing on Linux are:

* An errc() function. I added one in compat.c of my diffstat output
above, and this accounts for most of the lines in the patches.

* Our make(1) uses arc4random(). #ifdef HAVE_ARC4RANDOM and a few
lines to call srandom() or srandomdev() and random() when it's
unavailable are probably `ok' for this.

* FreeBSD make uses getprogname(), but saving argv[0] and re-using
that is trivial to add when HAVE_GETPROGNAME if undefined.

* On FreeBSD/pc98 systems make tries to get the value of the
"machdep.ispc98" by calling sysctlbyname("machdep.ispc98", ...).
Since this part of the code is to be able to build make on pre-7.0
FreeBSD/pc98 systems, it may be ok to #ifdef HAVE_SYSCTLBYNAME and
ignore this compatibility code on non-FreeBSD systems.

This pretty much sums all the source code changes I had to make to build
on Linux and Solaris. I'll see how much of the changes I can clean up
and post online at `http://hg.hellug.gr/bmake/gker/'. It should be
pretty easy, so please ping me in a couple of days if I haven't followed
up with an "ACK, all done now".

The 'porting' of share/mk/bsd.*.mk files may be a bit trickier, and it
may even turn out to be much more difficult. I can certainly use all
the help I can get there...

- Giorgos

_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

> hard to do. Nowadays, with a great number of the changes having been crafted to
> change dependencies to FreeBSD-only tools, it's a real bear to port it.

If you are looking for a portable BSD-compatible make(1) you could try
the "portable"
version of NetBSD's make(1). This is available at:

http://www.crufty.net/help/sjg/bmake.html

There are a small number of differences between the languages accepted
by this make
and FreeBSD make, but for the most part they are compatible.

Koshy
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

Chuck Robey writes:
> [BSD make should really be GNU make]

cd /usr/ports/devel/automake110
make install clean

DES
--
Dag-Erling Smørgrav - des@des.no
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alfred Perlstein wrote:
> The only excuse I have for top posting here is that I agree
> with the entirety of this email.

Well, thanks, I wanted to get a feeling if I was alone in feeling this way; I
guess I'm not. With this in mind, I've ported our BSD make tool twice (I lost
my first try, felt fairly stupid for having to do it twice). Now I have this
much agreement, I feel good enough about this to begin my own effort to make all
the changes I asked for. I intend to code up changes in separate patches, so
folks won't get a "all or nothing" option from me. My only problem in this is,
since my health went bad on me, now I'm kinda more disabled than I used to me, I
can't work as many hours as I used to, so it's definitely going to make me
longer than most others. On top of this, I honestly don't cooperate all that
well. I can take orders fine, but I generally either do it all or let YOU do it
all, I'm just not a really great team player. So, if you have the time, leave
it to me, I'll get it done, but if you want it soon, well, you might want to do
it yourself.

Other than that, I don't much see where this needs more discussion right now,
unless someone has some more suggestions about what changes you want. I'm only
(myself) interested in code portability, version options, and make conditionals
test capabilities. I don't really want to craft a copy of GNU make. We can
discuss this more when I have patches to show off. Once again, thanks for the
clear, rapid response.

>
> -Alfred
>
> * Chuck Robey [080827 10:28] wrote:
> I am posting this to our arch list; if I'm wrong, we can move this. I want to
> argue for some changes to our great make(1) tool.
>
> I've long been a fan of make, and in particular, FreeBSD's make. In my own
> career, I've often had to do more custom creation of Makefiles, and while there
> are some folks here who definitely DO know our make better, I think I can
> honestly say I know it pretty well. In creating tools for customers, I've
> often been forced, unwillingly, to go to the GNU make tool. The reason is just
> one of compatibility. There are several different reasons for this, which I
> want to list:
>
> 1) while the GNU make has the -v to allow one to both identify the tool and the
> version, FreeBSD's make has no such facility, that I'm aware of. You can't test
> & capture the type of make here, except by the rather inadequate trapping of
> getting no response at all.
>
> 2) while some parts of our make don't advertise it, they can be made compatible
> to the gmake's tools. "include" is a good example (the FreeBSD "include" docs
> claim that it only works as ".include", but that's a prevarication (and a very
> good thing it is). What I'd like to argue for is that some things like "if"
> have their compatibility with gmake enhanced. No, don't make it a mirror image,
> just make it possible for a programmer to craft a limited set of tests that will
> work in both places.
>
> If you give programmers the ability to detect what make they're in, the ability
> to craft a limited set of compatible tests, and also the other side (endif
> stuff) then everything else for portability can be done by using those limits.
>
> If something like this were done, then it allows a programmer, finally, to write
> a REALLY portable makefile. It would still allow one to make use of all of
> make(1)'s great command set, but not to kill it's use in a gmake-only system.
>
> OK, that'st the major argument. I'm going to ask for one thing here, but it's
> truly extra, just my own bias's showing thru. I wish that a fair number of the
> changes that have gone into make be taken back. I'm not talking about those
> that enhanced it's operation, I'm talking about all of the changes that, while
> trying to increase the elegance of the code, have really destroyed it's porrting
> portability, in a major way. Make used to depend on a smaller set of libraries,
> and those libraries were largely those available on other systems, so the task
> for a programmer, to port our make(1) to a different platform wasn't all that
> hard to do. Nowadays, with a great number of the changes having been crafted to
> change dependencies to FreeBSD-only tools, it's a real bear to port it.
>
> The code involved is nearly all very, very portable; it's the way that the
> libraries have been constituted that makes porting this a really bad job. If
> someone would make up a libmake.so.1, which in itself could be make really
> portable, that would also go a great long way to improving the popularity of our
> make(1). I'm NOT asking to roll back any of the distinct improvements that have
> gone in, only the changes that ruined it's porting-ability (yea, that's
> portabilty, I just wanted to really point that out again).
>
> OK, if someone were to come up with swuch a set of changes, would they be dead
> on arrival? I know that no one gets prior approval for FreeBSD (I completely
> agree with that), just didn't want to be totally at odds with everyone, if I'm
> the only one who sees it this way.
>
> Thanks for your time.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAki3OgsACgkQz62J6PPcoOl00gCgjo1YlwlDSr cahO8DK+VijWx/
w90An028vyzNklvjS97D/yv5qO+IDquP
=ADNQ
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"