gcc-6

[René J.V. Bertin]

On Wednesday May 18 2016 12:28:47 Ryan Schmidt wrote:

>Naturally a hypothetical gcc6 port that only provides a Fortran compiler would take less space and less time to build than one that also provides C, C++, and Java compilers. But then other ports that expect C, C++ or Java compilers to exist in the gcc6 port would fail to work. Other ports need to be able to declare a dependency on another port and be assured that the port contains the things they need.
>
>Using variants to enable different languages is therefore not workable because MacPorts does not have the capability to declare dependencies on a variant of another port. So the only possible way it might work is by creating a subport for each language.

Hmm, yes, I hadn't thought of that. This is not entirely true though: there is a way (via a PortGroup) to check whether the appropriate variant(s) is/are active.

>Besides that being a lot of work, I don't know if the gcc build system is arranged so that building different languages separately is possible. We

I've been fooling around with this idea in the past couple of days, using accumulative variants (and an "all" default variant). I haven't tried building only the Java compiler because that's the one that interests me least, but I noticed a couple of things that make the whole topic rather moot:
- building the C compiler without the C++ compiler is apparently impossible
- the C compiler is required to build the Fortran compiler (and thus C++ is built too)
- building the Ada compiler requires at least gnat, which hasn't been maintained for a long time

So it seems that the only feasible things are skipping the ObjC and/or ObjC++ compilers, and the Java compiler. I'll try to round up my "little" experiment to assess if that makes a lot of difference in installation footprint.

There's always the possibility to provide variants to omit components like Java and/or ObjC. But maybe ObjC is actually the only component where this is justified (?) because the language is almost certainly better supported by Clang ... and users who are space-constrained enough to care about the reduced install footprint might not have enough space to build the port from source anyway.

>separated libgcc into a subport some time ago, but that works by having both the libgcc port and the gccN port build everything, then delete the 
>parts that aren't needed in the post-destroot phase, which is wasteful and makes the build take twice as long as it used to before the separation

Yes, it's really a pity that there is no way to split packages that doesn't require building everything as many times. 
OTOH, you could try to convince upstream of the interest of a target for building only the runtime libraries corresponding to port:libgcc . That would at least reduce the build time for that (sub)port.

>The gcc build uses a 3-stage process, which, as I understand it, includes compiling the compiler, then using the compiler to compile itself again. That means the compiler for all languages used to write the compiler itself would be needed.

Yes, that's always been the case. It's a classic, exhaustive bootstrap procedure, starting with a gcc version built by the platform compiler. This is then used to build a stage 2 compiler that should be full-featured except for features that cannot be built with the stage 1 compiler, but that doesn't have any optimisation. It is however capable to build the final compiler in all its glory. Stage 3 is also a large-as-life unit test: the compiler should be able to build a bug-free copy of itself.
This is undoubtedly why you get the C compiler, and presumably also C++. However, it shouldn't be necessary to build that or those in the 3rd stage. GCC is shipped as the exec built by stage 2 GCC, why would Fortran or Java have to be built by stage 3 GCC rather than stage 2 GCC? (Rhetorical question!)

>Building a compiler is a complicated affair, and the gcc6 portfile is already over 260 lines long. I don't really want to complicate it further. Not to mention that a build takes hours, so making and testing any extensive changes would be extremely time consuming.

It takes a bit over 1h on my 2011 2.7Ghz i7, using a very high nice value and only 3 jobs. Still, I agree, it's an expensive toy when incremental building isn't possible (like here).

R.