9 Aug 2002 08:41
grand unified theory
Kevin Van Vechten <kevin <at> opendarwin.org>
2002-08-09 06:41:30 GMT
2002-08-09 06:41:30 GMT
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)
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
RSS Feed