On Aug 3, 2007, at 4:19 PM, Chris Pickel wrote:
How would that script be run? Each user manually at their own
discretion? Or through some upgrade glue internal to MacPorts? I
would very much prefer the latter approach, something like my
"upgrade" target in base/Makefile.in (later on I'll remove all
that code once we consider enough time has gone by to upgrade most
of our user base to the macports namespace, in the mean time I'm
sure we can share that target for other upgrade purposes).
I had assumed an 'upgrade' target. However, since the script is
external to the Makefile, it wouldn't be difficult to do the second
method
When I said "internal to MacPorts" I was referring precisely to the
upgrade target in base/Makefile.in (as opposed to a tool, some
separate script, that the user has to run manually after reinstalling
MacPorts, which is what I meant by the implied "external"). So I
guess we're in "violent agreement" there ;-)
- i.e., at the end of mportinit, if file doesn't exist $
{registry.path}/registry/, source ${prefix}/share/macports/scripts/
reg_upgrade.tcl
I would personally prefer a Makefile target, MacPorts innards are
already quite filled with upgrade hacks here and there to account for
stuff we've changed in non backwards compatible ways throughout our
history; but I'll let you be the judge for what'll work best for your
upgrade. On a related note, cleaning up the legacy cruft would be
lovely, IIRC registry1.0 is filled with it and I'm positive we don't
need it any longer ;-)
OK. So to be clear, if I commit to trunk, there will be no trouble
with keeping it out of 1.5.1? Then I'll go ahead and commit.
There shouldn't be, regardless of svnmerge.py if I have careful and
detailed eyes. But now that you mention it, it's no secret that
waiting until I merge to release_1_5 and release 1.5.1 will only make
my life easier (I do have to analyze trunk to figure out what I'll
merge). So if you're not pressed to commit then I guess waiting a
couple of days will not hurt.
I'd encourage you to do the same for registry2.0 and later on
figure out what tool we use to produce the docs if doxygen can't
handle the tcl format, what matters the most is that the
documentation is already there in place.
Alright. I think I'll probably use the doxygen style, but use /*
instead of /**. Tools won't detect it as documentation, so they
won't screw up when they try to associate it with the function
signature ;)
Most cool! Having the documentation already in place will rock,
later on we'll figure out how to extract it on an automated basis.
Chris
Thanks for this great work, Chris. Keep it up! Regards,...
-jmpp
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
