Is it still worth splitting up gcc/gfortran/etc. into completely separate derivations?

[copumpkin]

Our gcc expression (all versions of it) is (understandably) fairly complicated today, but it also has many booleans for enabling java, ada, vhdl, objective c, and fortran.

I'm wondering, if it's as necessary given multiple outputs nowadays? My intuition is that our various combinations of (most of) those flags share a ton of code generation compilation, plus some different language-specific front-ends (perhaps different for java). It might not add significant time to compilation to unconditionally build most of those and to put them into separate outputs? Has anyone experimented with this?

A more precise statement of this issue could be "share with multiple outputs where the shared work is high, and add flags where it isn't". So for example I'm staring right now at two simultaneous super-long builds of gfortran and gcc, which I'm pretty sure are sharing 90%+ of the work, but I need to wait for both of them because of the current expression structure.

cc @shlevy @edolstra @vcunat

[shlevy]

👍 for me. Though honestly the real fix would be to get gcc to split up the build 👅

[shlevy]

Also, we have a nifty new mechanism for soliciting community feedback!

[dezgeg]

I think you will run into bootstrapping issues from things like:

++ (optionals langJava [ boehmgc zip unzip ])

[shlevy]

We can always add another bootstrapping phase 😉

[vcunat]

Fortran doesn't need any extra input, so there it might be cheap.

[butterflya]

I have a meta comment, which is that I'd like to see a higher standard for proposals.

[copumpkin]

This was a question since I don't know much about the highly complex gcc expression beyond what I said: that I occasionally need to make changes to it and building several highly correlated derivations that all take several hours to build, to make sure my change works, is unpleasant. @butterflya If you have an issue, can you be more specific about who should do what differently?

…

On Sat, Apr 8, 2017 at 08:13 butterflya ***@***.***> wrote: I have a meta comment, which is that I'd like to see a higher standard for proposals. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24708 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAKPxoD8koQ7dbGeoOsimt4FpFThhOuks5rt3ntgaJpZM4M236D> .

[butterflya]

@copumpkin Nix has various use cases. One of them is that whoever deployed something knows what exactly got deployed due to the cryptographic guarantees.

You just want to be able to quickly iterate. Nix currently does not support that.

What you are doing is that you have a particular problem (making small changes induces a long delay) and then you generate some solutions in that in a couple of minutes and share that with the rest of the world instead of taking the time to write down exactly what you want.

Nix could easily have a mode where the supplied cryptographic properties can be programmatically disabled for example. This is just one way to get around the problem.

Another one is to provide a compiler cache, perhaps one which is even shared across everyone who is running Nix globally (which could be done if it was done in a very secure manner).

Yet another way to solve the problem of support for a particular language would be to kill gcc support entirely. It's not as if gcc is a high quality compiler and its build system also leaves much to be desired.

If a build system for a particular project is not incremental, we could also make it such that it becomes incremental if upstream absolutely doesn't want to cooperate.

Finally, a problem I have with the issue you have submitted (and many others also do) is that it is not at all clear how much better it needs to be before such an issue is considered done. We don't even have metrics in this case saying how long it currently takes on even a given piece of hardware, let alone something standardized (I am sure that can be found in Hydra, but the issue reporter should do that work).

In order to compute the answer to your question, we would first need to know how long gcc would still exist within the context of NixOS (which even depends on individual participants) and how much it would cost to bring it to some required level assuming the specification for what you want is made clear.

I have no doubt that one could do incremental builds of gcc in 10 seconds; it's just that you would have to discard gcc's build infrastructure completely and it would cost a pretty penny.

Just to be clear; I also generated the above solutions in a couple of minutes. Do not interpret these as if I propose these as solutions. There is no point in thinking about a solution if there isn't even a clear problem to solve.

[copumpkin]

@butterflya a couple of points:

1. Agree that this bug isn't particularly actionable. We (or I at least, and I've seen others do it too) often use the bug tracker for questions and community discussion (note the existence of the "community feedback" label that I applied here), and this was intended along those lines. It's not particularly pleasing to purists, but I'm happy to close this once we've resolve that it's either infeasible to merge the derivations or we've actually done it
2. Preaching at (comparatively) long-time Nix users about what Nix is and is not won't get you many brownie points. I've spent the past couple of years of my life doing my best to advance the state of what Nix is, so you giving me a point-in-time summary of what it is doesn't really sway me much. I understand perfectly well that Nix is bad at incremental recompilation within projects (I've probably recompiled LLVM+clang from scratch more times than many LLVM developers have because of this) and I'm saying in this ticket that there's probably an opportunity to reduce that, without revamping the entire Nix model. I don't want to remove gcc or figure out if it's here to stay or anything particularly world-shaking. I'm just saying that the community at large (and Hydra) is probably rebuilding a ton of stuff unnecessarily that could be fairly trivially shared between those derivations without deeply changing the expression or the underlying compilation model. That's it.

Edit: sorry, rereading this, it sounds unfriendlier than I meant. I'm just not sure, concretely (short of questioning whether gcc is a good long-term investment or changing the underlying Nix build model) what you think I should be doing differently here. If you think it's a question better posed to the mailing list, I could buy that, but I find that the issue tracker tends to get more eyeballs, and allows me to highlight people and ties in better with the repository.

[butterflya]

@copumpkin Basically, you now have a hypothesis that there might be a way to do "X", because there is "a ton of stuff " which you claim is built unnecessarily (i.e. contains repeated work).

I don't like such existential statements. If someone were to get at the same level of knowledge as you are on this issue, this person would first need to build the projects you are talking about and find what is actually overlapping. You claim things as if they are facts, but for me they are just unproven assertions, even though I could imagine your statements to be true.

So, first provide prove that some other system configuration does not suffer from this problem with numbers (takes X seconds using Debian 8 to build package foo with all features on a particular machine) vs Y, Y >> X on Nix. If that cannot be established, I don't see why this issue is here instead of in the bug tracker of upstream.

The way I see it is that you want to do things before you have the infrastructure available to solve them. I.e., try to walk first, before you run a marathon.

Regarding 1., I think all issues opened should have been well considered before creating a new issue.

Regarding 2., you are now saying that if you have done a lot of other useful work on Nix that it's then OK to break the rule to think about something before asking a question. I don't think I need to explain how this is not social. I also don't think that the community at large is building gcc all day long; it's a specialized use, but that's a separate issue.

[copumpkin]

Yeah, you're right that I could've put up some data. The way I was thinking about this was admittedly less useful on a broadly available bug tracker, and assumed knowledge on the part of certain recipients. If you notice above, I highlighted specifically a few people that I know have experience with this particular expression. I had a hypothesis and figured it would be easier to rely on their experience with the expression rather than spend several hours of my day experimenting with it. Indeed, we see above that @vcunat adds some useful information that gfortran can probably be shared trivially, based on his knowledge from working with it.

When each individual build ends up taking at least a couple of hours, I figured it would a better use of everyone's time to just ping people who probably knew off the top of their head, rather than bother "making a big case" for why this was the right or wrong thing to do. If I knew for sure, I'd probably just make the change myself.

I'm not saying that I should be exempt from the rules. I'm saying that you're referencing a rule that doesn't really exist. Sure, it's always better to file issues with as much concrete information as possible, but given the extensive shared context between various team members, in many cases it seems easier for me to rely on that. In an ideal world that wouldn't happen but we're all doing this in our free time and this seemed like a better trade-off. To put it differently, given scarce time, these feel like the options to me:

1. I have this thought (that the structure of the gcc expression is doing a lot of unnecessary work), but keep it to myself because I don't have (or am unwilling to spend) time to build a watertight case for it.
2. I have this thought and spend hours of my time figuring it out, either leading to an improvement in the expression or leading to nothing, which means I just wasted several hours of time.
3. I do what I did above, which is to throw a quick thought out to the community to see what others think. That takes a few minutes of my time and asks experts in this area to voluntarily contribute a few minutes of their time to chime in. If they say it sounds promising, I (or someone else) can invest more time into actually improving the expression.

It sounds like you're advocating #1. Either way, if you'd like to take this to the broader community, may I suggest the mailing list? I'd really prefer this issue not to be bogged down with meta-issues, since I do actually care about what I'm asking about in here.

[7c6f434c]

«I also don't think that the community at large is building gcc all day long;» — I don't think we have that many issues that touch the entire community at large.

« If someone were to get at the same level of knowledge as you are on this issue, this person would first need to build the projects you are talking about and find what is actually overlapping. » — people tagged, and people with less but still significant experience in the question, have read enough logs of gcc builds to know that bootstrap does overlap and this overlap is annoying…

[vcunat]

What I wrote wasn't much about my knowledge but about looking into our current expression and seeing how the langFortran switch is used.

My personal feeling is that doing more in a single derivation might bring additional complications, as we would need to add fortran executables and fortran libs as additional outputs, probably forcing us to move them from the place where install scripts put them. Still, it may go OK.

[Ericson2314]

See #26004

I want more derivations, and less rediculousness per derivation, eventually.

[copumpkin]

@Ericson2314 I do too, but I also don't want massive expressions that deviate significantly from how upstream treats things and are only understood by 2 nix contributors, so everyone else is afraid to touch them. The two goals don't have to be at odds, but it'll take exceptional creativity/cleverness to get a simple expression that also produces independent derivations 😄

[mmahut]

Are there any updates on this issue, please?

[stale]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/gcc-separation-of-language-frontends-and-the-print-prog-name-option/9116/1

[stale]

I marked this as stale due to inactivity. → More info

[patka-123]

Hello @copumpkin 👋

I was wondering if you still have this issue. If there is no problem anymore would you mind closing this issue?

(I'm going through issues marked as stale to see what can be triaged. If this is still a valid issue then don't mind me)

[Ericson2314]

This is still a good idea, and hopefully @amjoseph-nixpkgs and I will soon do something quite related.

[ghost]

Our gcc expression (all versions of it) is (understandably) fairly complicated today, but it also has many booleans for enabling java, ada, vhdl, objective c, and fortran.

I think the booleans will always be necessary since

1. not every language frontend works on every platform
2. we need at least --languages=c (only) and --languages=c,c++ (only) for bootstrapping, so langC and langCC will always be around.

However:

I'm wondering, if it's as necessary given multiple outputs nowadays?

Separate outputs from a single build would be nice, but I don't think gcc's build machinery supports splitting up the build products into a separate --libdir= for each language, does it? If upstream has a supported way to make it do this then we could try moving to a single big multi-outpath build.

The other issue is that debugging cyclic references between outputs of a single derivation is a massive headache at the moment... cppnix's error message gives no hint as to which files the cycle passed through, and very helpfully deletes all the evidence if you're using remote builders. :(