Package depending on any one of multiple FLAVORS

[Matthew Seaman]

On 06/02/2018 09:51, Ondra Knezour wrote:
> Hi gang,
> 
> documentation is little sparse yet (found only mention in the Porters
> handbook, created PR for "end user" doc) and I am unsure, if we can
> handle this. Best way I can describe my question is probably via
> examples, so consider following:
> 
> We have multiple PHP versions in ports (php56, php70, php71, php72)
> which may get flavored in future. Now there is also some simple PHP
> application, let say php-composer, which would work with any of those
> PHP runtimes. Can we handle it in some generic way or should one create
> also multiple flavors for given application?
> 
> Another example would be some really simple C program, which can have
> any C compiler as build time dependency. Here making multiple flavors
> doesn't have any sense, but author knows that any compiler will suffice.
> This one is more general, because it is not only about flavors, but may
> lead to something like from [clang4-5, gcc4-6, intel, whatever we have]
> take one, but you got the point.
> 
> Same can be asked probably for all interpreted/scripting languages like
> Ruby and Python and many simple scripts in ports which doesn't have
> other dependencies beside those interpreters. Simple Java applications
> may also run with all or most available Java ports etc.

No, unfortunately at the moment you'ld need to create a different
package for each of the different flavours of PHP you wanted to depend
on.  The good news is that it takes relatively little code in the port's
Makefile to do that.  Assuming it grows FLAVOR support, the minimum
you'll need is eg.:

   USES+= php:7.1+

In many cases where there is an explicit dependency line you need
something like:

   RUN_DEPENDS+= ${PHP_PKGNAMEPREFIX}foo>0:something/php-foo@${FLAVOR}

(or possibly ...@${PHP_FLAVOR})

This is down to a deficiency in pkg(8) -- it can't handle having a
number of alternate packages or ranges of different package versions to
fulfil a dependency.  The dependencies "baked into" each package are on
exactly the dependency package and version used at compilation time.

	Cheers,

	Matthew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 992 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20180206/4d377658/attachment.sig>