-
Notifications
You must be signed in to change notification settings - Fork 841
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better split-objs support #3656
Comments
I believe that split-objs has some compiler and linker overhead. Possibly not, though, as it doesn't need to load as much overall object code into memory. Worth trying it out! One approach might be to add it as a configuration option that can also go in your global config.yaml, so you can enable split-objs globally if you want it. |
It has some overhead, it can make the compilation process much slower. But you misunderstand, the option is already there, it is just marked as experimental and the built binaries are not seperated from the normally built ones. Which means i always have to turn it on. Sometimes, I don't need smaller binaries and i would like to turn it off without 'dirtying' my snapshot with bigger binaries. |
Ah, yes, indeed it already is part of configuration. Well you can just put the following in your
I can buy that having separate binary results for this would be nice. I think that will fall under the umbrella of #3330 |
Dunno why I closed this |
I've been using the
split-objs
option everywhere for what I believe is over a year now. During this period it has caused zero problems and it produces significantly smaller binaries.However, it's annoying that packages built with
split-objs
are not seperated from packages built normally. So it needs to be enabled all the time if you want the full benefit.I wondered for how long this feature will remain experimental because it seems to work really well and it would nice for it to be fully supported.
The text was updated successfully, but these errors were encountered: