#540 Define gcc and gcc-c++ as providing minimal C and C++ compilation environments.
Closed: Fixed None Opened 4 years ago by codonell.

The current Fedora Packaing Guidelines have a section at ​https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2 which was changed by https://fedorahosted.org/fpc/ticket/497 to clarify that all build requirements should be listed.

This change has caused some confusion about which core packages to require for C or C++ development.

The rationale for the suggested text is a desire to avoid all C and C++ application developers from having to list all of the internal packages which constitute the implementation of a C and C++ compiler and runtime.

There should be similar text needed for other language compilers and runtimes.

I suggest the following text be added to this section:

== !BuildRequires for C and C++ applications ==

If your application is a C or C++ application you should list a BuildRequires against gcc or gcc-c++ respectively. Those packages will include everything that is required to build a standards conforming C or C++ application. You need not include a BuildRequires on glibc-headers, or any other package unless you have a specific and special need e.g. static compilation. The default use case of a dynamically compiled C or C++ application is taken care of by the gcc or gcc-c++ packages.

If your library includes standard C or C++ headers, you need not have a devel package Requires on glibc-headers or any other standard language headers package. The end-user of your library will add BuildRequires: gcc or BuildRequires: gcc-c++ to their spec files to compile with your library and that will be sufficient to include the needed standards conforming headers.

If at runtime you use cpp to process C or C++ langauge headers then you have no choice but to Requires: gcc or Requires: gcc-c++ to get all of the required headers for a standard conforming C or C++ application. In the future this recommendation might change if a set of standard C or C++ language headers are provided by a special-purpose provides.


I don't agree with making standard library headers something special. I cannot see a reason why not have both the dependencies: foo-devel including standard headers would run-require glibc-headers and bar build-requiring foo-devel would build-require gcc because the bar calls the gcc.

I don't know how Fedora supports other toolchains, but image someone wants to install foo-devel because he builds his local code by llvm or icc. I still think separating the headers from compiler makes sense. At last for C code. C++ is something different as there is no standard ABI.

Other use case is to install foo-devel because someone wants to process the headers by cpp only (for example to create a binding). Then the compiler is not needed which cannot be said for standard library headers.

Maybe it's more academic disputation because the overwhelming major use of devel packages is to build them with gcc, so the codonell's approach is more pragmatic. And maybe I just don't understand it and modern compilers cannot be split from the standard library anymore.

I just wanted express my concern about introducing asymmetry between standard library headers and other headers which has to be in our minds and tools anytime we handle the dependencies.

I agree with Petr, i.e. I do not agree with this proposal.

From a ordinary package's perspective glibc is not any different from any other library package.
I.e. packages, which want to build against glibc should "BR: glibc-devel" (ie. if the glibc folks want to drop glibc-headers, the appropriate replacement would be "BR: glibc-devel").

Replying to [comment:2 ppisar]:

I don't agree with making standard library headers something special. I cannot see a reason why not have both the dependencies: foo-devel including standard headers would run-require glibc-headers and bar build-requiring foo-devel would build-require gcc because the bar calls the gcc.

Petr, Thank you very much for the comments. I appreciate your review.

The standard library headers are special, they form a multi-package implementation of the standard C and C++ development environments.

The package glibc-headers is not the standard headers, it is only part of them, and which parts, and which other packages are needed is implementation dependent and maintained by the Fedora platform tools team (gcc, glibc, binutils, etc.)

If you want to avoid encoding the name gcc or gcc-c++ in packages, we can add a c-devel or c++-devel metapackage that installs the default e.g. gcc or gcc-c++ respectively.

If we want symmetry then foo-devel should run-require c-devel, and build-require c-devel. The gcc package is the only package that ensures you have all the require standard headers.

I don't know how Fedora supports other toolchains, but image someone wants to install foo-devel because he builds his local code by llvm or icc. I still think separating the headers from compiler makes sense. At last for C code. C++ is something different as there is no standard ABI.

The headers cannot be separated form the compiler, they form a singular implementation. Even for C code you cannot split the headers, there are implementation details within the headers that constitute a singular implementation. The implementation also extends to clang as I'll explain.

If you are using clang, then the composition of the clang package headers and the glibc (pacakge and subpackage) headers, an possibly gcc headers, constitute the coordinated C development environment implementation.

And clang already run-requires gcc-c++ to ensure all implementation headers are correctly installed, and thus the clang package is a good example of the right set of run-requires.

Therefore you could install foo-devel, which run-requires the default c-devel or gcc, and then install clang, and build with clang.

Given that c-devel or c++-devel do not yet exist, I recommend depending on gcc or gcc-c++.

Other use case is to install foo-devel because someone wants to process the headers by cpp only (for example to create a binding). Then the compiler is not needed which cannot be said for standard library headers.

The compiler headers are needed to create a complete header implementation for standard C, and those headers are included in the gcc package.

Therefore it is correct for foo-devel to run-require gcc.

It is a Quality of Implementation issue though, that the compiler, which you don't use, is also installed.

If this becomes an issue we could discuss with the Fedora platform tools team to create a way to minimize the installed files for this use case. We would likely split the gcc headers into a subpackage and provide a metapackage of c-headers that installs what the user needs. Again, this is a QoI issue, not a problem with the distribution build-requires or run-requires.

Maybe it's more academic disputation because the overwhelming major use of devel packages is to build them with gcc, so the codonell's approach is more pragmatic. And maybe I just don't understand it and modern compilers cannot be split from the standard library anymore.

That is the problem. That the runtime and the compiler constitute an implementation that cannot be split. If it is split we would need a metapackag e.g. c-headers to create a closed set of headers, and this hasn't been done.

I just wanted express my concern about introducing asymmetry between standard library headers and other headers which has to be in our minds and tools anytime we handle the dependencies.

If we want symmetry then foo-devel should run-require gcc, and build-require gcc. The gcc package is the only package that ensures you have all the require standard headers.

Was I able to answer all of your questions?

My goal here is to clarify exactly what developers should be doing for C and C++ packaging. If I did not make that clear, then I'm happy to expand on the topic and update the proposed text.

Thank you again for your time, review, and patience.

Replying to [comment:4 corsepiu]:

I agree with Petr, i.e. I do not agree with this proposal.

From a ordinary package's perspective glibc is not any different from any other library package.
I.e. packages, which want to build against glibc should "BR: glibc-devel" (ie. if the glibc folks want to drop glibc-headers, the appropriate replacement would be "BR: glibc-devel").

Unfortunately that is not true, glibc is different from other library packages, it is a core component of an ISO C standard implementation.

As I explained in my response to Petr, the glibc-devel package is an insufficient dependency to provide all of the headers.

Here is an updated v2 text:
- Provide symmetry between build and runtime requirements.

= !BuildRequires for C and C++ applications =

If your application is a C or C++ application you must list a BuildRequires against gcc or gcc-c++ respectively. Those packages will include everything that is required to build a standards conforming C or C++ application.

If your library includes standard C or C++ headers, you must list Requires against gcc or gcc-c++ to install the needed standards conforming headers.

If at runtime you use cpp to process C or C++ langauge headers then you have no choice but to use Requires for gcc or gcc-c++ to install the required headers for a standard conforming C or C++ application. In the future this might change if a set of standard C or C++ language headers are provided by a special-purpose provides e.g. c-headers or c++-headers.

Note: You need not include a BuildRequires on glibc-headers, or any other package unless you have a specific and special need e.g. static compilation. The default use case of a dynamically compiled C or C++ application is taken care of by the gcc and gcc-c++ packages.

Updated v3 text:
- Mention clang.

= !BuildRequires for C and C++ applications =

If your application is a C or C++ application you must list a BuildRequires against gcc, gcc-c++ or clang. Those packages will include everything that is required to build a standards conforming C or C++ application.

If your library includes standard C or C++ headers, you must list Requires against gcc, gcc-c++, or clang to install the needed standards conforming headers.

If at runtime you use cpp to process C or C++ langauge headers then you have no choice but to use Requires for gcc, gcc-c++, or clang to install the required headers for a standard conforming C or C++ application. In the future this might change if a set of standard C or C++ language headers are provided by a special-purpose provides e.g. c-headers or c++-headers.

You need not include a BuildRequires or Requires on glibc-headers, or any other core C or C++ implementation package unless you have a specific and special need e.g. static compilation requires the *-static library packages. The default use case of a dynamically compiled C or C++ application is taken care of by the gcc, gcc-c++, and clang packages.

I don't agree with this proposal for a couple of reasons:

  • It's way too long to put in the guidelines. We could conceivably add such documentation for a whole range of packages, and the intent of the original was to remove a bunch of needless verbosity. Adding back more isn't really useful.

  • It basically duplicates the existing guideline. "Depend on what you need in order to build."

  • It documents internal GCC dependency issues, which could change.

But feel free to collect this kind of information somewhere on the wiki.

Replying to [comment:8 tibbs]:

But feel free to collect this kind of information somewhere on the wiki.

Where can we provide a global answer to the question "What do I depend upon if I'm a C or C++ program, now that the buildroot is minimal?"

Should we include a section on the same wiki page but at the end?

I'm looking to head off questions posed by developers.

It's a wiki; just make a page. I'm not going to bikeshed about the name. I can add a link from the guidelines once it exists.

Replying to [comment:10 tibbs]:

It's a wiki; just make a page. I'm not going to bikeshed about the name. I can add a link from the guidelines once it exists.

For now: https://fedoraproject.org/wiki/C_and_C%2B%2B

Is it possible to get this under Packaging:C_and_C++ and linked into Application Specific Guidelines?

It won't be moved under Packaging unless it goes through the usual FPC guideline amendment process.

Replying to [comment:12 tibbs]:

It won't be moved under Packaging unless it goes through the usual FPC guideline amendment process.

I am not familiar with that process. Do you have a link to it so I can start that?

Replying to [comment:15 codonell]:

Replying to [comment:12 tibbs]:

It won't be moved under Packaging unless it goes through the usual FPC guideline amendment process.

I am not familiar with that process. Do you have a link to it so I can start that?

That's basicaly what this ticket is the start of. Open a ticket, provide a policy change, get votes.

I am somewhat sympathetic to the desire to head off troubles for anything dropped from the "default" buildroot, I'd guess the most likely to be accepted would be a minor note somewhere saying "If you want to build C/C++ applications, as would happen by default before F22, then require gcc-c/gcc-c++". If you want more than that I'd try to catch tibbs on IRC.

Replying to [comment:16 james]:

Replying to [comment:15 codonell]:

Replying to [comment:12 tibbs]:

It won't be moved under Packaging unless it goes through the usual FPC guideline amendment process.

I am not familiar with that process. Do you have a link to it so I can start that?

That's basicaly what this ticket is the start of. Open a ticket, provide a policy change, get votes.

I am somewhat sympathetic to the desire to head off troubles for anything dropped from the "default" buildroot, I'd guess the most likely to be accepted would be a minor note somewhere saying "If you want to build C/C++ applications, as would happen by default before F22, then require gcc-c/gcc-c++". If you want more than that I'd try to catch tibbs on IRC.

That makes sense to me, and that text might only be needed for a one release as the transition happens.

I would prefer the following solution:

  • File ticket to promote https://fedoraproject.org/wiki/C_and_C%2B%2B to packaging guideline
  • Add "If you want to build C/C++ applications, as would happen by default before F22 please see <link to="" new="" c="" c++="" packaging="" guideline="" page="">"

Can this ticket stand for the latter or is too messy now?

Any progress? Current packaging guidelines mention gcc only at three places and none of them is about including standard library header files. Maybe a new Application Specific Guidelines section for C language should be added there pointing to the linked page.

Filed this ticket specifically to request the C/C++ page be linked in under Application Specific Guidelines:
https://fedorahosted.org/fpc/ticket/578

This way when users have problems with the minimized buildroots they can review exactly what is expected of their C/C++ application.

This ticket remains open to discuss changing the top-level guide to include something about "If you want to build C/C++ applications, as would happen by default before F22, then please see the Application Specific Guideline for C and C++." as james suggested.

FWIW, I would vote to include this information in the guidelines under "Application Specific Guidelines".

I don't view this as any different to the list of BR/Rs for java applications that we maintain here: https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires

I have no problems including some C/C++-related document under the application-specific section either. In general I think that with the proliferation of programming languages in use these days (many of which are completely self-hosting), the C compiler doesn't occupy quite the special place it previously had and it would be good to stop treating it as something magic which doesn't need to be specified as a dependency.

Would the committee folks want to move the document under the Packaging: hierarchy in the wiki, or would linking to a "non-official" page for this information be acceptable?

Also, I think we may have skipped consideration of this ticket for quite some time because it was siting in the needinfo state. I've moved it to the meeting state so hopefully we can get this wrapped up on Thursday.

Replying to [comment:22 tibbs]:

I have no problems including some C/C++-related document under the application-specific section either. In general I think that with the proliferation of programming languages in use these days (many of which are completely self-hosting), the C compiler doesn't occupy quite the special place it previously had and it would be good to stop treating it as something magic which doesn't need to be specified as a dependency.

Exactly, and this is the kind of behaviour we want to document to continue to support minimal build roots.

Would the committee folks want to move the document under the Packaging: hierarchy in the wiki, or would linking to a "non-official" page for this information be acceptable?

My preference would be to move the page under Packaging, but only if that allows the Fedora Toolchain team to continue to expand it to provide the best answers for C/C++ specific packaging problems.

Also, I think we may have skipped consideration of this ticket for quite some time because it was siting in the needinfo state. I've moved it to the meeting state so hopefully we can get this wrapped up on Thursday.

Thank you!

Replying to [comment:23 codonell]:

Replying to [comment:22 tibbs]:
[...]

Would the committee folks want to move the document under the Packaging: hierarchy in the wiki, or would linking to a "non-official" page for this information be acceptable?

My preference would be to move the page under Packaging, but only if that allows the Fedora Toolchain team to continue to expand it to provide the best answers for C/C++ specific packaging problems.

Wiki pages under Packaging are maintained by the FPC as they're the official guidelines. Maybe we should put just the BuildRequires and Libraries sections from your draft in the Guidelines and the rest can remain on a freely-editable wiki page as it is now.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-11-12/fpc.2015-11-12-16.00.txt):

  • 540 Define gcc and gcc-c++ as providing minimal C and C++


    compilation environments. (geppetto, 17:09:56)
  • LINK: https://fedorahosted.org/fpc/ticket/540 (geppetto, 17:10:09)
  • ACTION: (geppetto, 17:23:46)
  • ACTION: Promote C and C++ page and link to it from main guidelines
    (+1:6, 0:0, -1:0) (geppetto, 17:24:18)

I had written this one up some time ago.

Announcement text:

A new page for guidelines specific to C and C++ has been added.
https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B?rd=C_and_C++
https://fedorahosted.org/fpc/ticket/540

Metadata Update from @tibbs:
- Issue assigned to tibbs

2 years ago

Login to comment on this ticket.

Metadata