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

[Enrico Weigelt <weigelt@metux.de>]

* 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/
---------------------------------------------------------------------