Re: [Chicken-hackers] Re: separate build directory support for Chicken

[Elf]

On Sun, 13 Jan 2008, Peter Bex wrote:

> On Sun, Jan 13, 2008 at 10:30:13AM -0800, Elf wrote:
> > a) who uses pkgsrc besides the bsds?
>
> Solaris people tend to rely on pkgsrc because it's the only sane way to
> install 3rd party packages.  There are even some Linux distros that use
> pkgsrc for their package manager.  I've used it on Mac OS X when I still
> used it to get my Unix stuff.  Worked great, and a lot more intuitive
> than macports (or do you prefer Fink?).
>
> Why are you talking about pkgsrc?  This was about pmake.

you brought up pkgsrc, and this post was in response to you saying that bmake
was common and widely available on the basis of pkgsrc.

> > b) from a brief look at the installation docs, yes, it does use bmake...but
> >     the first thing the bootstrapper does is build it and install it.  it
> >     comes with pkgsrc.  if the package has to bootstrap its make before it
> >     can build itself, thats a fairly good indication that its not a common
> >     utility.
>
> This is desirable: pkgsrc has to be self-sufficient.  How are you going
> to install make and the various other infrastructural tools it needs
> otherwise?  Using another package manager?  Why are you using pkgsrc then?

well, personally, i dont use a package manager.  havent since the mid 90s. 
ive built everything on my boxen by hand, and from what i can tell its not 
nearly as bad as using a package manager.  you didnt respond to my point,
however: it has to bootstrap its make.  even on other bsds.  which means that
its not a common use utility.  searching around for a bit showed me that 
it seems that NOTHING aside from this uses it by default.  postgres used to,
but doesnt seem to anymore.  this is not a tool id expect to see on most 
boxen.  conversely, gnu make is so ubiquitous at this point that its becoming
increasingly rare to even see "You must have GMake (GNU Make) installed to 
build this package!" in the readme.  while i may be ill prepared to discuss
the technical merits of whichever bmake you fancy, i can say that its not 
on most boxen.  given a choice between having to install a custom build
system or just find a different implementation, i would wager that most people
would choose the latter.  especially given the nature and quality of the 
bug reports on non-<whichever-bsd-this-particular-bmake-is-for> systems.

> > c) looking at the build notes for the various platforms for pkgsrc... if
> >     this is supposed to be BETTER, i fear whats worse.  the toolset isnt
> >     even consistent between platforms.
> >     eg,  solaris: gnu binutils not supported, yet gcc is preferred strongly.
>
> No idea about this.  Remember that it's much more likely that this is about
> about building of the packages themselves rather than the bootstrapping
> process (which is where make is built).  For example, it's very likely that
> a lot of software in pkgsrc makes silly assumptions about the build
> environment.  Like "oh, we're on Solaris, so we're using Sun utilities".
> Hardly pkgsrc's fault.  Or relevant to the BSD Make discussion we were having.
>
> If you really want to know, ask on the pkgsrc mailinglist.

no, this was taken only from the BOOTSTRAPPING section of the documentation. 
as this discussion was supposed to be about bmake, i was only
interested in its availability, use, features, maintenance, build process,
and commonality.  i didnt read about how pkgsrc can improve my life or whatever
it was they were selling, only about issues related to bmake.


> >          darwin: it needs its own filesystem, which disables journalling on
> >                  the base filesystem.
>
> This is because pkgsrc includes a lot of Unix tools, and many of these
> programs assume a case-sensitive filesystem.  If you extract a tarball which
> includes files with mixed case filenames, this will break. This is _not_ a
> bmake deficiency.

fair enough, on this point.  saying something is supported whilst simultaneously
saying its very dangerous and requires one to boot from cd is not a strong
argument, though. :)

> >          all forms of bsd besides netbsd: warnings about how it can bork their
> >                                           native toolchains.
>
> Not toolchains, but package managers.  pkgsrc uses the same names for the binary
> programs it installs as these other systems.  pkg_add, pkg_delete, pkg_info.
> This is hardly relevant to the BSD Make discussion.


if 'make' is part of the toolchain, then warnings about their native toolchains
getting borked.  mk.conf conflicts.

which brings up yet another point, namely, which bmake are you proposing? 
and how many bug reports and assorted nightmares will there be if someone
builds, or tries to build, with the wrong bmake, and doesnt realise it?
and why are there so many incompatible bmakes anyway?

> > d) this is an improvement?  i can see why gnu's make is so popular.
>
> You didn't raise a single objection against BSD make, but rather against pkgsrc
> and why you think it doesn't work.


fine, i will spell out my objections to bsd makes, yet again:
1) not a common or previously existing tool on most boxen
2) not well maintained for implementations other than whichever bsd wrote it
3) proliferation of utilities with the same name (bmake) not only with
   differing support and compatibility with other systems, but also with
   each other.  the bug reports will never end from people using the wrong
   one and getting strange results.
4) no port of any of em to at least 3 of the currently supported chicken ports
   (cygwin, mingw, mingw-sys, hpux)

as repeatedly stated, im not arguing the technical merits of whichever bmake
you prefer.  i am arguing only from the point of view of our continual
ease-of-maintenance, ability to support, and barrier for entry for new users.

are you proposing that we package bmake with chicken?  the current pcre 
fiasco should have been a warning in that regard.  without doing so and 
putting a fairly large amount of work into our version, we'll lose several
ports, have a never-ending slew of bug reports, dissaude new people from
switching to or using chicken, and suck up a lot of time we could spend 
on improving chicken, writing eggs, or other fun shtuff.  especially as 
chicken support in the major distributions is so spotty or out of date, 
anything we do to make the build process less straightforward will have a 
directly negative effect on chicken's future growth and prosperity.

in other words, it doesnt matter if bmake is the best thing to happen in 
computing since mccarthy's paper: if its not widely available and its not
easy to get and its quirky in its compatibility, it will hurt us.


-elf

> Regards,
> Peter