On 19 Aug 2010, at 17:38, Ryan Schmidt wrote:
> On Aug 19, 2010, at 09:04, Anil Madhavapeddy wrote:
>> On 19 Feb 2010, at 20:33, Ryan Schmidt wrote:
>>> The revision has to be an integer, as does the epoch if you use it. But the
>>> version can be pretty much any string you want, if you want to include the
>>> ocaml version in there. For example, in dcraw and molden, we shove the
>>> release date into the version, too, since the developers of those software
>>> packages keep releasing new versions without changing the version number;
>>> looking at those portfiles might give you ideas.
>>>
>>> I've also thought of doing the same for curl-ca-bundle. Its version number
>>> is the version of the curl source code (7.20.0), but it also downloads
>>> certdata.txt from Mozilla, a file whose version (currently 1.58) increases
>>> independently of curl's. So I considered giving curl-ca-bundle a version
>>> number like 7.20.0-1.58.
>>
>> I've finally gotten around to doing this, since OCaml-3.12 is out and all
>> the dependent ports need checking.
>>
>> One question: what's the best way to figure out the current version of ocaml
>> in the Portfile?
>>
>> The obvious way is to do:
>>
>> version 1.2.5-[exec ocamlc -version]
>>
>> ...but this fails if ocaml is not installed at the point the dependent port
>> (in this case, caml-findlib) is installed.
>>
>> I guess the other way is to hardcode the latest version of ocaml in the tree
>> in the version number; can this be shared across all ocaml ports easily?
>
>
> You wouldn't run ocamlc -version in the port; you would hardcode the current
> version number, and when a new ocaml is rereleased, manually update
> everywhere it was hardcoded.
>
> I suppose it could be done in the portgroup somehow. But for example for the
> bundled php5 extensions, I just hardcode it in every port. Somehow it didn't
> feel right to be fiddling with ${version} outside of the portfile itself.
That's fine, except that if the user doesn't actually upgrade their ocaml
compiler but just the port, then the hardcoded version is actually wrong.
e.g. i have:
ocaml-3.11
caml-findlib-1.2.5-ocaml-3.11
installed
then a new upstream versions come in:
ocaml-3.12
caml-findlib-1.2.5-ocaml-3.12
If the user just does a 'port upgrade caml-findlib', they would have it
compiled with the older version of the compiler, and things would break.
It would be a lot easier to be able to have a port depend on an *explicit*
version of a subport, so caml-findlib-1.25 could depend on =ocaml-3.11. Is
that difficult to add in as a feature in the current Macports infrastructure?
-anil
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
