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

finally subscribed

Is there an archive of the discussion so far ?
I assume there must be...

I don't know if Chris forwarded my earlier comments to the list.
On the one hand, I'm not too optimistic at the prospect of a completely
unified BSD ports/package tree.

On the other hand, I'm quite willing to explain issues specific to
the OpenBSD ports tree, and to incorporate improvements from other
BSD, when they make sense... also to try to be more considerate to
other BSDs and to write better patches.

I'm not at all interested in name bickering (packages, ports, who cares ?)
unless there are some practical issues involved.

One question I'm pondering: is there any reason (except historical) to
name patches, patch-aa, patch-ab... ?

We recently switched to using an update-patch script which names patches
along the lines of patch-filename, with some underscores substituted for
subdirs, which makes patches vastly more simpler to  match against the 
distributed software.

If people are interested, I'll try to draw a list of the make changes I wrote
which are specifically related to the ports tree. My effort so far has been
- to speed up make (and bsd.port.mk), with very good results. The
infrastructure  itself is about three to four times as fast as it was some
time ago.  Besides plugging in a very fast hashing library (with features
that make it better for make than what's currently in other BSDs), there also
was a lot of streamlining in the list library (which removes most of the
dynamic aspects of lists, which are thoroughly unneeded in make), and
a rewrite of the parser (in progress). This means that lots of variables,
.for loops, or loads of comments don't have the impact on Makefiles they
used to have.
- to improve POSIX compatibility. There was a suffixes bug that was fixed
six months ago, and a very important change that allows for variables
set on the command line to be passed to submakes (which simplifies faking
- to stamp out various bugs and add small features, such as regularizing
variable lookup in the context of conditional, or the recently proposed
`looking up targets along the VPATH' for sanity reasons (for which I have
to write a few lines of code yet).

This is a somewhat major endeavor. The complete diff for that was larger
than make source itself at some point (yep, I pretty much read all of
make's source and rewrote a large portion of it). It is now nearing the
point where I don't see obvious improvements.

As Hubert pointed out, the pkg_* tools are a sore point. Looking at that
code makes one cringe. It would take a lot of guts to start that 
from scratch, but this is something that needs to happen at some point 
in my opinion...  I have this scheduled for OpenBSD. The main problem I see 
is that there are fairly good reasons to rewrite this in perl, which is 
not a problem at all for all systems that include perl in their main 
distribution (one major good point is that you can examine packages on any 
machine that has perl without needing to compile anything. Another good point 
is that you don't have to invent a new scripting language, and you can even use
OO concepts, or compartments for safety (see Safe(3p) ), also you don't
have to fork a new shell for everything, which means that the perl version
ought to be as fast or faster than the current C one), but which is going
to be a stumbling block for NetBSD as I see it currently...
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'

To unsubscribe: send mail to <majordomo@unixathome.org>
with "unsubscribe bsdports" in the body of the message