[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: finally subscribed
On Tue, 29 Aug 2000, Marc Espie wrote:
> One question I'm pondering: is there any reason (except historical) to
> name patches, patch-aa, patch-ab... ?
no good reason that I can see. NetBSD has added some artificial
restrictions, but they can probably made undone easily.
> 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.
Er, I read that as a lot of internal code change (new hash lib, ...), and
one change visible to the ports system, the passing down of variables that
you're using for the fake builds? (not to belittle your work, I'd never
dare to touch make sources :)
What other changes did you make that made OpenBSD make(1) different from
what it was before (and what one might use FreeBSD or NetBSD make(1) for)?
> 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.
perl does the compilation each time you call the script, not once, so I
doubt that'll be a win. Esp. on old & slow machines. (think vax, 25MHz
m68k or 16MHz i386/sx).
> Another good point
> is that you don't have to invent a new scripting language, and you can even use
> OO concepts,
That you could use in C++ as well.
And from my personal POV it seem that C++ OO may be preferrable over perl
> or compartments for safety (see Safe(3p) ),
# man -s3p Safe
No entry for Safe in section(s) 3p of the manual.
It's fine to use such libs if one has them in tree, using them for a
project that most targets don't have it won't help us.
> 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),
First, I don't think that any of the pkg_* tools are time critical.
Then, the C code makes shell-callouts for things that aren't trivial to
code - I don't know if you intend to rewrite tar(1) in perl ... :-)
Most things that are called via system(3) now in pkg_* can be rewritten in
C if the need should arise.
No, you didn't convince me that perl's needed. :)
Nor a rewrite, actually - besides pkg signing and pkg upgrading, the
NetBSD pkg_* have everything available that I'd like to have for now in
NetBSD. Rewriting the whole pkg_* suite just to have them in perl sounds
like a waste to me. YMMV, of course.
Anyways, assuming'd have the current pkg_* rewritten in perl, what would
you do next?
NetBSD - because Unix isn't just #include <linux.h>, i386, ILP32, ELF, ...!
To unsubscribe: send mail to <email@example.com>
with "unsubscribe bsdports" in the body of the message