Closed #660.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/660#event-2320800907___
Rpm-maint mailing list
Just submitted a somewhat more elaborate update to the build flags (and yes
including ldflags) system: #692
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Ok, I'm closing the pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/660#issuecomment-489600068___
Rpm-maint
May I please ping this..
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/660#issuecomment-488596568___
Rpm-maint mailing list
OK, I've updated the pull request based on the discussion that we've got so far.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
As one of the maintainers of
[`rpm-config-SUSE`](https://github.com/openSUSE/rpm-config-SUSE), I'm okay with
this idea and we could work out a plan for transitioning things to the
convention in `redhat-rpm-config`. I like them more than the ones in the SUSE
environment, as it's clearer what
> I think switching to `%{build_…}` convention makes much more sense. In the
> old times where `optflags` meant everything, nowadays you want to have
> different CFLAGS, CXXFLAGS. And having `%{build_cflags}` but `%{ldflags}`
> sounds inconsistent.
I'm fine with the `%build_ldflags` name which
I think switching to `%{build_…}` convention makes much more sense. In the old
times where `optflags` meant everything, nowadays you want to have different
CFLAGS, CXXFLAGS. And having `%{build_cflags}` but `%{ldflags}` sounds
inconsistent.
--
You are receiving this because you are subscribed
> No objection to adding LDFLAGS to %configure, it's actually long overdue.
> Fedora has had its own version of this for a quite some time now, but nobody
> got around to upstreaming it. This seems like as good time as any to take a
> look at that and consider which parts would be upstreamable.
No objection to adding LDFLAGS to %configure, it's actually long overdue.
Fedora has had its own version of this for a quite some time now, but nobody
got around to upstreaming it. This seems like as good time as any to take a
look at that and consider which parts would be upstreamable.
There
Motivation for the change:
I'm planning to enable LTO in `openSUSE:Factory` and I need to add `-flto=N` to
LDFLAGS in order to make LTO linking phase parallel. That speeds up package
build significantly.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
marxin commented on this pull request.
> @@ -1021,6 +1021,7 @@ package or when debugging this package.\
CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \
CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \
FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \
+
Conan-Kudo requested changes on this pull request.
> @@ -1021,6 +1021,7 @@ package or when debugging this package.\
CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \
CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \
FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \
+
13 matches
Mail list logo
