shim for gcc / clang or package based info which compiler is used #124
Labels
No Label
blocked upstream
bug
build-failure
duplicate
enhancement
help wanted
informational
invalid
invalid/corrupt package
packaging issue
priority: high
question
support
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: ALHP/ALHP.GO#124
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
For more advanced flags to be used we need to provide a list for gcc and one for clang, as they use different flags.
I think this is solved for gentoo by providing an info which compiler is beeing used and thus will remove the unsupported flags.
We could do something similar by having two lists of optional flags for each compiler, so they would just get added depending on which compiler is stored in a variable for each package.
Another option is a shim which takes the place of the clang/gcc binary and adds the flags we want kinda dynamically. This wouldn't require us to keep track of the package's compilers.
I could write a bash shim for that, if you're interested in going this route @anonfunc
As easy as this sounds, who/what does maintain the lists? ALHP can detect the compiler while building sure, but probably not before. Manual sounds like hell.
Writing the shim would probably be the easy part. How to integrate it into the build without some hacky packages applied with
--overwriteis the question here. And ideally, ALHP should be able to modify the shim or the shim needs to somehow get the things it needs to do (versus a static shim). I though about using a socket bound into the chroot to communicate with the shim, but that sounds like overkill.Give me some time, I'll think about it. Maybe something good pops up.
Nah, that's rather simple, as the list is basiclly just part of this project: It's the flags AHLP like to set, like the ones TBD here.
I started writing the shim just as an experiment, I'll report back :)
Sure, easy. Add a readonly mount to the chroot, like '/cool_shim' and add it in the the first position of the $PATH. Most build envirments will probably search in the path for the compiler and not assume a fixed path. The shim on the other hand will use a fixed path to the binary and thus call the real binary.
The shim doesn't need nothing, it's completly static like the utils.go right now with the replacements.
Sure :)
Oh seems like I misunderstood. I was assuming you wanted to maintain a list of package -> compiler. That would be insane work. Yea separate list for compiler are fine, ofc.
Yea, I totally forgot about using the $PATH. That could probably work for almost all projects.
Yea, about that. I want to rework that section, since that was a stopgap-measure to begin with. I want to have them separate in a config commited into git, so we can track flag changes more easily. I'll do that as soon as I find time.
So, in that regard, having a dynamic shim would spare us of maintaining two files where flags are set.
I think the shim should be static and just be fed by enviromental variables, like the regular CPP flags are as well.
So something like
CPP_FLAGS_GCC="-list -of -awsome -flags"
CPP_FLAGS_CLANG="-list -of -other -flags"
and the shim will just take the regular CPP flags, add the GCC/CLANG flags, depending on the compiler called, and "clean" the flags given by the buildroot from everything we don't want to.
I'm somewhere around interation two, as I wasn't happy with the first one I haven't pushed it. ;)
So we can just have a file which get sourced by the shim in the git. So the shim is static and won't be modified, and we can supply custom flags if we have to - for example for the multilib builds.
That could also work, sure. Now we just need to figure out how to 'install' the shim into the chroot copy before building.
I just finished porting the compiler flags to a separate config file. Adding more build-env-vars should be cake now.
Somehow this dropped at the back of my head, sorry for that.
So we still need this for the project, correct?
I guess the best solution would be, to create a package for the shim and add it to the repository.
This way the package could be just added as an additional package to be installed in the chroot before the build starts. The package would then prepare the environment while beeing installed to use the shims.
If we want to have things like #134 I think it is still needed yes.
Yep, that was my understanding too.
I guess reading the flags.yaml makes the most sense, to specify what the shim should do, right?
If I add the required fields in the process, would your software ignore them?
You can add completely new vars to the flags.yaml and they get exported in their respective makepkg.conf. Shim could use these to decide what to do I guess? Or is there something more sophisticated needed?
Ah, okay!
I thought about putting the current version of the flags.yaml into the package and read the yaml file with the shim. But true, makes more sense to read the makepkg.conf for flags.
What's needed is a general definition of what each flag should do and then for the build itself which flags should be used.
So like the common.cflags defines currently that '-O2' should be replaced with '-O3'.
So the shim should need the flags.yaml (or a similar file) available inside the chroot. The question is: Do we want to package the flags.yaml into the package of the shim, or should the flags.yaml be copied while creating the chroot into the chroot?
Splitting the definition and the active flags allows overriding the flags per package. So if a package does not build with option X, we can just disable it by not setting it in the makepkg.conf.