Bug 197219

Summary:	Insufficient compiler information provided by Uses/compiler.mk
Product:	Ports & Packages	Reporter:	Shane <FreeBSD>
Component:	Ports Framework	Assignee:	Port Management Team <portmgr>
Status:	Closed Feedback Timeout
Severity:	Affects Some People	CC:	marino, portmgr, yuri
Priority:	---
Version:	Latest
Hardware:	Any
OS:	Any

Description Shane 2015-01-31 07:34:00 UTC

Currently Uses/compiler.mk provides COMPILER_TYPE ALT_COMPILER_TYPE COMPILER_VERSION and ALT_COMPILER_VERSION which covers the one(or two) compilers installed in the base system. Between 9.x and 10.x we have gcc as default and clang as default, with the user having buildworld options to switch that and to not install the second compiler.

Then we have CHOSEN_COMPILER_TYPE which is fine as we can tell which compiler will be used to build our port, but we don't know what version it is or what features it has.

The variable COMPILER_FEATURES is set using the default compiler. Obviously this list needs to be generated to decide if the default compiler is up to building the port, but within a port Makefile we really only want to know about the compiler that will be used to build the port. Sometimes the features of the compiler and or it's version may be wanted to choose which CXXFLAGS to be used, or choose patches that need to be done based on the version of the compiler. While source files can easily be patched to handle this, the build structure used for the port may not be that easy.

Also pointing out at this stage that there is no feature list for the alt compiler, which may be able to fulfil the requested compiler features without needing a compiler from ports.

Sometimes it would be helpful to know the version and features of the compiler that will be used when building the port, adding the variables CHOSEN_COMPILER_VERSION and CHOSEN_COMPILER_FEATURES would fulfil that need.

I am inclined to think that a db of compiler/version/features may need to be put together and used to set these variables rather than testing if a compiler works with xxx options sent to it.

Comment 1 Baptiste Daroussin freebsd_committer

2015-01-31 12:32:20 UTC

Any patches to improve the situation is more than welcome, just keep in mind that populating the _FEATURES macros is time consuming we try to avoid it.

Providing the CHOSEN_* might be not that easy as the chosen compiler might not yet be installed when this code is run (like it will add a dependency on clang34 which is not yet installed to we cannot run the command to query this compiler)

Comment 2 Shane 2015-02-02 05:18:56 UTC

What if a preset database of compiler information was used?

This would only be a few KB of text that could easily be grep'd or preset variables to test, with some conditionals to set all the relevant variables.

So if the default compiler is gcc 4.2 and alt compiler is clang 3.1, the requested feature can be searched for in gcc42 clang31 and higher versions until a match is found. Then the chosen compiler can be added to BUILD_DEPENDS, CC/CXX/CPP can be set and chosen compiler and version can be set to match.

Comment 3 John Marino freebsd_committer

2016-02-05 08:19:34 UTC

I'm inclined to close this PR since there's been no feedback in 1 year.

As an aside, dports caches this information and it saves a ton of time, but that's easy when you have 1 arch and not like 6.

Since, it'd definitely possible to do what FreeBSD@ShaneWare.Biz suggests because DragonFly does exactly that for great performance gains.

Comment 4 John Marino freebsd_committer

2016-02-05 08:19:54 UTC

sorry, didn't mean to close.