tools/manjaro-chrootbuild
3
0
Fork 0
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions

[util-chroot] enalble lto by default #32

Closed
philm wants to merge 1 commit from lto into master
pull from: lto
merge into: tools:master
Conversation 4 Commits 1 Files changed 1 +3 -1
philm commented 2022-06-21 09:28:45 +00:00 (Migrated from gitlab2.manjaro.org)
Copy link
- Enable link time optimization (LTO) of packages by default by adding the -flto flag. This provides smaller, faster executables/DSOs, and improves GCC diagnostics. - Arch didn't enable it in pacman package, hence add it here - see also: https://gitlab.archlinux.org/archlinux/devtools/-/commit/16b7a0e7e8ef795621172cb08887a2f86f0b0222 - see also: https://gitlab.manjaro.org/yochananmarqos1/manjaro-chrootbuild/-/commit/8ea4e8daa1f4b672bd61c57ccbcab7e3d37679c4
oberon commented 2022-06-21 09:41:02 +00:00 (Migrated from gitlab2.manjaro.org)
Copy link

same as https://gitlab.manjaro.org/tools/development-tools/manjaro-chrootbuild/-/merge_requests/16

like I said back then. My position is, if we want to use lto by default we can enable it in our pacman overlay. if we want it as an option it can be included as an option in chrootbuild.
'patching' it in as a pseudo-default in chrootbuild like this to me make no sense at all.

same as https://gitlab.manjaro.org/tools/development-tools/manjaro-chrootbuild/-/merge_requests/16 like I said back then. My position is, if we want to use lto by default we can enable it in our pacman overlay. if we want it as an option it can be included as an option in chrootbuild. 'patching' it in as a pseudo-default in chrootbuild like this to me make no sense at all.
oberon commented 2022-06-21 09:53:04 +00:00 (Migrated from gitlab2.manjaro.org)
Copy link

I think the cleanest way will be to use a dedicated flag for chrootbuild, like we do for debug builds.
My point is I am not happy about obfuscating the actual pacman default by patching stuff in the chroot.
Another advantage of including it with a flag of course is that both build strategies can still be used by whoever wants to do it which way.

I think the cleanest way will be to use a dedicated flag for chrootbuild, like we do for debug builds. My point is I am not happy about obfuscating the actual pacman default by patching stuff in the chroot. Another advantage of including it with a flag of course is that both build strategies can still be used by whoever wants to do it which way.
oberon commented 2022-06-21 11:41:37 +00:00 (Migrated from gitlab2.manjaro.org)
Copy link

I am including a flag for this option. Please don't just push the same commit while you have already opened a MR and we are in discussion about the change. makes no sense at all.

I am including a flag for this option. Please don't just push the same commit while you have already opened a MR and we are in discussion about the change. makes no sense at all.
oberon (Migrated from gitlab2.manjaro.org) closed this pull request 2022-06-21 11:41:38 +00:00
oberon commented 2022-06-21 11:51:15 +00:00 (Migrated from gitlab2.manjaro.org)
Copy link

mentioned in commit 326308712b

mentioned in commit 326308712b7e2a591c07d0d204d56c0b9ea2307c

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
tools/manjaro-chrootbuild!32
No description provided.