Am 10.01.18 um 23:56 schrieb Jim Trigg: > ISTR that there is a more generic variable that will cause make to work with > all flavors instead of the default "common" set. Not where I can easily look > up specifics right now...
FLAVOR support has many rough edges and I expect those to hurt us in one way or the other in the future. A lot of them could easily be fixed, but a sound design should have covered them from the beginning. There is no generic ALL_FLAVORS variable, but some of the generic FLAVOR support implemented in Mk/Uses does offer a way to access all FLAVORs. In the case of Python ports, you have to pass -D BUILD_ALL_PYTHON_FLAVORS to make to get FLAVOR set to all supported Python versions/flavors: $ make -V FLAVORS py27 py36 $ make -V FLAVORS -D BUILD_ALL_PYTHON_FLAVORS py27 py36 py35 py34 The upcoming Emacs flavor support will use a different parameter and for any of the many individual ports, that support flavors directly in their respective Makefiles, the variable will have a local name. There seems to be a clear opinion in the portmgr team, that not all flavors of each port shall be built by the package build cluster, but only those that are most commonly used (e.g. py27 and py36), which I understand because else there would be thousands of additional python packages (and later perl and others) that are hardly ever used. But there should still be provisions to obtain a full list of flavors in a generic way. (I had used "FLAVORS" to denote a list of all supported flavors and e.g. PKG_FLAVORS for those that are selected for the package builders, but FLAVORS for the selected set and ALL_FLAVORS for the complete set will do as well ...) I'm not going to work-around such deficiencies in the design of FLAVORs in portmaster. I'd have to follow each new port that is converted to flavors to check whether it has all flavors in FLAVORS and which other name it uses for a list of possible FLAVOR values (if such a list explicitly exists at all, it could also be implicitly present in the form of control structures in the port's Makefile). I'll ask portmgr for a few small changes (a generic ALL_FLAVORS variable and a make target that lists all package names and corresponding flavors for a port), and I hope I get approval for these changes. For now I'll have to develop a method that at least partially compensates the missing FLAVOR support features required for port management tools. Regards, STefan _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[email protected]"
