On Wed, May 16, 2012 at 11:34 PM, Julien Puydt <julien.pu...@laposte.net> wrote:
> Le mercredi 16 mai, Robert Bradshaw a écrit:
>> I don't like spkg.txt because it's just a (under-specified) convention
>> of what to put there when you make manual changes. Better would be to
>> have some specification file (json?) like
>>
>> { upstream = "http://original.project/releaseX.tar";,
>> upstream_sha1 = "...",
>> excise = [ "windows.exe", "binary.blob" ], # remove from the above
>> when creating our tarball (below)
>> sources = "project.X.tar",
>> sources_sha1 = "...",
>> patches = [ "fixOne.patch", "fix2.patch" ], # to be applied to
>> sources, once unpacked
>> }
>>
>> Then an spkg could be automatically generated by changing the upstream
>> url (most common case), and otherwise one could tweak/meddle with src
>> and automatically create a new patch once you get it working.
>>
>> This may be a pain to do with shell scripts (how do you parse a json
>> file?) but perhaps a lot could be cleaned up if we assumed *some*
>> python as a prerequisite.
>
> May I suggest that instead of writing JSON then trying to parse it...
> just write a shell script (see below for the type of shell script I
> have in mind)?
Parsing JSON is easy in a proper language with the right libraries,
and easier to manipulate and re-write programmatically (e.g. when
automatically creating the patch files). I could see storing other
metadata (including dependencies) in that file as well that one would
want to reason with. The makefile idea has merit though.
> Instead of the "upstream*=" things, just have two lines of script to
> download and check the hash.
+1
> Instead of and "excise=", just have the needed 'rm -rf' lines.
+1
> I don't see what the "sources*=" are about if you already downloaded
> and checked the tarball.
There's 2 tarballs here, the actual upstream (that we don't typically
ship with Sage) and the purged one (that we do).
> What use if there for a "patches=..." list if you have the patches in a
> patches/ directory already?
They may not commute. I suppose they could be numbered/otherwise
ordered based on their names.
> That could be done by a Makefile file with mandatory rules (which
> could then be called by a script) with things like :
>
> .PHONY: unpack patch configure build install
>
> patch-stamp:
> @echo 'Applying patches'
> <patch commands>
> @touch patch-stamp
>
> patch: unpack patch-stamp
>
> unpack-stamp:
> @echo 'Unpacking sources'
> <unpack commands>
> @touch unpack-stamp
>
> configure-stamp:
> @echo 'Configuring sources'
> <configure commands>
> @touch configure-stamp
>
> configure: configure-stamp
>
> build: unpack configure build-stamp
>
> You get the idea,
>
> Snark on #sagemath
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
