chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Elf
Subject: Re: [Chicken-hackers] Re: separate build directory support for Chicken
Date: Sun, 13 Jan 2008 12:03:35 -0800 (PST)


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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]