exact version dependency for ocaml libraries

[Anil Madhavapeddy]

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