> I've updated all spkg's so that they now have an hg repo with the
> directory structure based on the one listed above. Comments and
> suggestions are welcomed. You can see them here:
> http://sage.math.washington.edu/home/dfdeshom/custom/spkg/
Fantastic! The naming convention for spkgs that includes the .pn
post-fix where n labels the spkg version is probably not needed now.
My understanding is that label was loosely used as a sort of version
control. I think simply having the hg repo for each solves that
problem. Also, there doesn't seem to be any real consistent approach
for updating those numbers. My though would be to get rid of them.
The other thing that I am not sure how to handle (part of this is my
lack of experience with hg) is the names of the directories
themselves, for example:
freetype-2.1.10.spkg
When freetype gets upgraded to 2.1.11, do we simply rename the
directory to freetype-2.1.11? Will hg be happy with that? Sorry, I
just don't know how hg treats directory renames.
> One note: I would prefer that READMET.txt be kept as SAGE.txt (or
> renamed to something else) because then it would be clear that
> modifications were made to the spkg. I tend to ignore README.txt's
> anyway because they don't tell you why you should read them.
I agree that README.txt is a little confusion, but because the spkgs
are being used outside of SAGE, I would name the file something that
emphasizes that it is really the readme for the spkg:
SPKG.txt
SPKG-README.txt
or something like that. One of the things I have been working on (on
my private copies) is to decouple the spkg build system from the
details of sage itself. This has mostly meant changing the name
"sage" to "spkg" in the context of the build system.
> On 6/1/07, Brian Granger <[EMAIL PROTECTED]> wrote:
> > 2. The other scripts/makefiles involved in the spkg build process -
> > like newest_version, install, save-env, etc.
>
> sage-env is under version control, but the others aren't.
> >
> > 3. The overall directory structure that contains the
> > scrips/makefiles. The reason this is important is that most of the
> > scripts make strong assumptions about where they are run from. Also,
> > as I have begun refactoring, some of the scripts have been moved
> > around (for instance newest_version has been moved to
> > base/spkg-newest-version). Managing this without the associated
> > directory structure is a pain.
>
> Are you talking about the scripts in SAGE_ROOT/local/bin ? Because
> they are under version control (this is where sage-env lives too).
I am talking about the both the directory structure that is needed for
the script/makefiles to function properly:
spkg/
standard/
base/
As well as the actual scripts and makefiles (deps, install,
newest-version, etc) that have to be in particular locations in that
tree to work properly. For instance, deps as to be in standard,
install in spkg newest-version in standard, and a bunch of stuff has
to be in base.
Once the overall structure of these new spkgs have settled down, I
will start to convert my private spkgs (I have things like (qt and
pyqt4, and a bunch of other things) into this form. Then contributing
them will be really simple.
Brian
> didier
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
