Re: [9fans] plan9 httpd/pegasus on unix?

[Uriel <uriel99@gmail.com>]

Pity you are so busy, we all would love so much to hear more of what
you have to say about lunix MTAs.

And please, keep us updated with every detail of your tireless efforts
to 'create' a GPL fork of qmail, that project would be of utmost
relevance and usefulness to Plan 9.

uriel

On Fri, Feb 29, 2008 at 7:16 PM, Enrico Weigelt <weigelt@metux.de> wrote:
> * sqweek <sqweek@gmail.com> wrote:
>
>
> > >  Well, this *very* unobvious and complex (instead of just passing $CC and
>  > >  $LD to make), requires me to maintain additional logic, which woulnd't
>  > >  be necessary, if DJB could write his makefiles in more standard and sane
>  > >  ways ;-P
>  >
>  >  The docs are a bit light on custom compilers, granted (probably as
>  > they're irrelevant for 95% of users), but INSTALL does point you at
>  > conf-users/conf-groups/conf-qmail. Doesn't take a genius to notice
>  > conf-cc and conf-ld from there.
>
>  It's not the point that it is written somewhere, but that it's very
>  different of the vast majority of the packages I'm using/maintaining.
>
>  I've got to maintain a several hundred packages for our emedded target
>  platforms. All of them MUST fit into an 100% automatic build process.
>  So it really matters if I have to develop (and maintain for a long
>  time) individual build rules for each package.
>
>  I would accept this if these individualities would serve an noticable
>  purpose, but I don't see that here. Not that I want to tell DJB how
>  to write makefiles (in this issue), but he must accept that doing such
>  trivial things totally different than 99% of the world isn't quite
>  user/maintainer friendly.
>
>
>  >  DJB's makefiles have the dubious honour of probably being written
>  > before such conventions existed. There is a reason he does it that way
>  > - Makefile dependencies only work with the timestamps on files. If you
>  > do it the "sane" way, then make has no information about the freshness
>  > of the information in CC.
>
>  Right, but actually I never had problems with this in recent 15 years.
>  "make clean" after changing toolchain settings should be obvoius.
>  *If* you really want to catch this, you an store the settings in some
>  file and compare it on next make run (almost trivial):
>
>  * some check rule (dependency for the other targets) compares the
>   current settings (eg coming from env) with the stored ones. If
>   they've changed, force recreate of the settings file
>  * the stored-settings file is created from the current settings
>  * all targets depend on the settings file
>
>
>  >  This is the motivation for DJB putting the commands into files
>  > instead of using the environment or make variables. That way he can
>  > have all the compilation rules depend on conf-cc so that should you
>  > change it, everything gets rebuilt properly. Similarly with the other
>  > conf- files - you don't need a make clean or anything after changing
>  > them, just make and exactly what needs to get regenerated will get
>  > regenerated. We're talking pretty marginal gains, obviously -
>  > recompilation is not expensive. It's mainly an academic achievement -
>  > having a *correct* Makefile.
>
>  Well, this approach is nice (probably useful for really large trees,
>  which BTW shouldnt exist at all ;-P), but has the drawback that you
>  have to take great care not to forget an single dependency to some
>  settings. And good chance for bugs ;-P
>
>
>  > >  >  Granted, the -include is a bitch and took me awhile to work out.
>  > >
>  > >  Actually, this is crap. Probably he just forgets the #include's.
>  >
>  >  Yes. There is history here again. If you hunt around you'll find
>  > posts from DJB complaining about unix (libc?) developers breaking
>  > existing code by making errno not work without including errno.h.
>
>  Then he probably complains that people fixed libc ? ;-O
>  Isn't this obvious that you have to include errno.h if you're using
>  stuff from it ? Seems like he just relied on someone else to
>  inlude errno.h ;-O
>
>
>  > >  >  The sysroot requirement is a little harder to meet, but really just
>  > >  > requires a mount --bind /tmp/sysroot/var/qmail /var/qmail. Or, if
>  > >  > you're running qmail on the host and really can't afford to stop it
>  > >  > for a minute or two, a custom setup rule based on hier.c (or use a
>  > >  > chroot - oh if only lunix had private namespaces...).
>  > >
>  > >  chroot != sysroot.
>  >
>  >  I'm well aware. If you were paying attention you'd notice I was
>  > suggesting a chroot as a method of putting a directory from the
>  > sysroot in the standard location without affecting the host system,
>  > not suggesting you attempt to chroot into a cross-compiled root.
>  >  And again, if lunix had learnt anything from plan9 this would be *trivial*.
>
>  Still doesn't help in any ways. DJB's makefile *runs* compiled code
>  on the compiling machine. This DOES NOT work on crosscompiling.
>
>  Sometimes it *MAY* work if host and target are compatible, which may
>  happen on my site as I'm also crosscompiling to same platform+arch.
>  For me, crosscompiling isn't just a way for gettings something built
>  for another platform+arch, but a integral part of build and QM process.
>
>  To catch such mixups between host and target, even when host can
>  run target's binaries, I first build the package for an incompatible
>  target to let it intentionally break when such mixups happen.
>
>  BTW: you didn't response to the compilied-in UID issue.
>  Rember: DJB takes the numeric UIDs/GIDs from the building host
>  and statically compiles them in.
>  This is very bad even for purely native builds. So everytime you
>  change some of these IDs, you have to completely rebuild qmail.
>  First of all, you HAVE TO BE AWARE OF THAT (I'm really interested
>  in what percentage of (potential) qmail users really know this).
>  As an distro maintainer you have to *ENSURE* that every individual
>  target system has the matching IDs to your building system.
>  A very critical design flaw in the makefile.
>
>
>
>
>  cu
>  --
>  ---------------------------------------------------------------------
>   Enrico Weigelt    ==   metux IT service - http://www.metux.de/
>  ---------------------------------------------------------------------
>   Please visit the OpenSource QM Taskforce:
>         http://wiki.metux.de/public/OpenSource_QM_Taskforce
>   Patches / Fixes for a lot dozens of packages in dozens of versions:
>         http://patches.metux.de/
>  ---------------------------------------------------------------------
>