Kevin Van Vechten | 9 Aug 08:41 2002

grand unified theory

here are some notes on the "grand unified theory" for ports which Jordan 
and I discussed this afternoon.  i'll start with a definition of flavors 
and then move on.

flavors are sets of options available for a port.  the user will specify 
a list of desired options, all of the flavors of a port will be scanned 
and the one that provides the closest match to the desired set of 
options will be chosen.  flavors may have dependencies, so those 
flavors' provisions and their dependencies, etc., will be read in.  The 
'vanilla' Portfile code is executed unconditionally, then the dependents 
to the selected flavor block will be executed, then the selected flavor 
itself.  Building will progress on to the targets, etc.  flavor syntax 
is as follows:

# 'vanilla' port code
portname superwhizbang
portversion 1.0
patchfiles p
flavor X {
      # flavor code goes here
      patchfiles ${patchfiles} yap
}
flavor A B C requires X Y Z {
      # flavor code goes here
      linkoptions ${linkoptions} -lX11
}

Where A,B,C are features provided, and X, Y, Z are flavors required.  
hyphens will be used for grouping, in order to sort out the ambiguity in 
the requires side... i.e. is X Y Z  three different flavors which each 
(Continue reading)

Jordan Hubbard | 9 Aug 12:42 2002

Re: grand unified theory

On Thursday, August 8, 2002, at 11:41 PM, Kevin Van Vechten wrote:
> flavor X {
>      # flavor code goes here
>      patchfiles ${patchfiles} yap
> }
> flavor A B C requires X Y Z {
>      # flavor code goes here
>      linkoptions ${linkoptions} -lX11
> }
>
> Where A,B,C are features provided, and X, Y, Z are flavors required.  
> hyphens will be used for grouping, in order to sort out the ambiguity 
> in the requires side... i.e. is X Y Z  three different flavors which 
> each provide only X, Y, or Z?  or is it two flavors, one providing X-Y 
> and the other Z?, etc.

You should probably illustrate some of the hyphenated examples so that 
folks understand that more thoroughly, but this all gibes with my 
understanding of what we talked about, yes.  Landon, this is really 
good, honest, it's not just a clever solution in search of a problem. 
:-)

It's probably also not a bad time to start nailing down some of the 
commands like "patchfiles", "linkoptions" and so on.  I actually think 
we should be careful about how "deep" we go into the individual ports, 
e.g. whether we even care about their link options or C compilation 
flags at the Portfile level.  I realize this may have simply been a 
contrived example and you didn't actually intend to imply that we 
should, but since you bring it up... :)  My feeling is that we should 
have all of our flags and commands at the "phase level", that is to say 
(Continue reading)

Kevin Van Vechten | 9 Aug 23:41 2002

dependency hierarchy

Jordan, this is what i was going to talk about as you left for work.

I'm not sure if this was made clear in my grand unified notes or not, but presently I'm imagining the
following hierarchy of valid dependences.

Items in this category: may depend on items in these categories.
Portfile:	Portfile
Target:		Target Portfile
Flavor:		Flavor Target Portfile

Why would it be invalid for a target to rely on a flavor?

The standard targets won't be relying on flavors.  The pre-/post- targets shouldn't rely on flavors,
because if the flavor they rely on isn't chosen, then the build will break at that point.  It would make more
sense to install a pre-/post-/override target from within the body of a flavor block.

Why would it be invalid for a Portfile to rely on a flavor?

Well a portfile obviously can't rely on one of its own flavors--that'd be circular.  It can't easily rely on a
flavor of another portfile, because in the case where where a port requires the "ogg vorbis" flavor of
bladeenc, (depspec =  bin:bladeenc:audio/encoders/bladeenc:oggvorbis), if the binary bladeenc is
found, how do we know it's really that flavor?

Lastly, Portfiles depending on targets of other portfiles seems of limited utility--might as well omit it
for simplicity.

-kevin


Gmane