On 10/13/2012 12:33 AM, Danek Duvall wrote:
So I'm preparing to dump a large number of python modules (~50) into
userland, and writing three manifests for each is getting a bit tiresome
(I've done three so far; I'm lazy). It'd be really nice to have this in
before I need to do more, but I need someone to actually review it.
I haven't checked to make sure it still applies since May, but I suspect
that any necessary changes will be small, obvious, and easily reviewable.
I suspect I'll want to make another change that will auto-generate (at
least most of) the version-generic manifests, too, but that can be a
separate change. I may work on that this weekend, and I'll put up a
pyver-v2 if I get it done before any reviews come in.
If someone could commit to reviewing this in the next week, I'd greatly
appreciate it. If not, I'm going to start pinging individuals. :)
I didn't look at the Perl changes, but I've a question/comment on the Python
side.
If I'm reading this correctly, it only does the expansion to cover all
PYTHON_VERSIONS if a manifest contains PYVER. Is that correct?
If not, then there would be problems with:
./python/python26/python-26-tests.p5m
./python/python26/python-26.p5m
./python/python26/tkinter-26.p5m
./python/python27/python-27-tests.p5m
./python/python27/python-27.p5m
./python/python27/tkinter-27.p5m
and at the moment, we don't have a Python 2.7 .p5m for Openscap.
Danek Duvall wrote:
Here's something I was playing with a few days go. The problem is that
when you have a package delivering a python module, you have to have a
separate, full manifest for each version of python, even though they're
essentially identical. This is a pretty ugly maintenance burden, since on
update, you have to tweak each one in exactly the same way, and every time
a new python version is introduced or removed, you gotta go add or remove a
ton of manifests. They should be autogenerated.
So here's an attempt at that:
https://cr.opensolaris.org/action/browse/userland/dduvall/pyver/
There are a couple of things to note:
- I've included the ability to do the same thing for Perl. It'll extend
indefinitely, though the way I managed to make make do this requires
that those definitions be somewhat intertwined.
- I'm not even remotely sold on the variable names; if someone has better
ideas, I'm all ears.
- The changes to shared-macros.mk are primarily for performance, though
IIRC, the WS_TOP change is necessary in order that its definition isn't
too slippery (I can't remember now the exact failure mode, though I can
retry that if anyone wants to know).
- The whole canonical-manifests rule was a royal pain in the butt. You'd
think it wouldn't have any effect on what I was trying to do, but it
definitely made things not work until I tweaked everything that used
it. I'm tempted to remove it, since I don't really see its purpose,
but left it in for now.
- Make is annoyingly fragile. And yet it deals with chained rulesets
better than anything else. <sigh>
- Assuming folks are okay with this, I'd rewrite all the modules to use
this, not just mercurial.
Thanks,
Danek
_______________________________________________
userland-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
_______________________________________________
userland-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
