I do not understand any rationale reasons why those macros have been removed.
Again: using those macros allows me build Linux ans Solaris/OpenSolaris
packages.
Only because someone don't know about something it does not mean that something
is useless :/
ALT is using rpm 4.x. So what will happens
@kloczek OpenMandriva does not use them in any maintained packages.
I do know that PLD and ALT are active heavy users of these macros, though
neither of them are using this version of RPM yet.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
Open Mandriva, Fedora and other distributions are using those macros from years.
PLD is using them as well from more than 14 years.
Please rollback this patch as it will break many distributions.
As well on using those macros on OpenSolaris with pkgtool is possible to mask
location of the auto
Mageira, OpenMandriva are using those macross on massive scale.
Fedora spec files are using those mscros as well.
You just broke many packages. Please rollback this patch
[root@domek SPECS.fedora]# grep __auto *
fastbit.spec:%{__autoconf}
fastbit.spec:%{__automake} --copy --no-force
I'll fix the cosmetics.
I also have patches to use doScript() for the running the buildRequires script
that removes a lot of duplicated code but have not made it into this PR yet.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Please clean up the recurring cosmetic issues mentioned above, and redo the
series to include later fixes from the start so we get a nice, logical patch
series for proper review.
Adding rpmtsFromPyObject() can be merged in the commit to pass rpmts to spec
build, because it's a small thing
pmatilai commented on this pull request.
> @@ -274,17 +414,22 @@ static rpmRC buildSpec(BTA_t buildArgs, rpmSpec spec,
> int what)
exit:
free(cookie);
spec->rootDir = NULL;
-if (rc != RPMRC_OK && rpmlogGetNrecs() > 0) {
+if (rc != RPMRC_OK && rc != RPMRC_MISSINGBUILDREQUIRES
pmatilai commented on this pull request.
> @@ -172,9 +174,113 @@ rpmRC doScript(rpmSpec spec, rpmBuildFlags what, const
> char *name,
return rc;
}
-static rpmRC buildSpec(BTA_t buildArgs, rpmSpec spec, int what)
+static rpmRC doBuildRequires(rpmSpec spec, int test) {
In case of
Merged #687 into master.
--
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/687#event-2320956804___
Rpm-maint mailing list
pmatilai approved this pull request.
...but then that doesn't mean we can't merge it, we already have one such
hardcoded limit in.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Move the logic from the huge switch-case to a table for sanity, only create
macros for the tags where it makes sense to do so.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/693
-- Commit Summary --
* Move the "tag is
Merged #691 into master.
--
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/691#event-2320907878___
Rpm-maint mailing list
Closed #688.
--
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/688#event-2320910375___
Rpm-maint mailing list
Ok, they are all gone now. Closing 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/688#issuecomment-489612820___
Rpm-maint
pmatilai commented on this pull request.
> +
+# C++ compiler flags. This is traditionally called CXXFLAGS in makefiles.
+%build_cxxflags %{optflags}
+
+# Fortran compiler flags. Makefiles use both FFLAGS and FCFLAGS as
+# the corresponding variable names.
+%build_fflags %{optflags}
Conan-Kudo approved this pull request.
Looks good, just one issue...
> +# compiler flags.
+
+# C compiler flags. This is traditionally called CFLAGS in makefiles.
+# Historically also available as %%{optflags}, and %%build sets the
+# environment variable RPM_OPT_FLAGS to this value.
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
Conan-Kudo commented on this pull request.
> +# compiler flags.
+
+# C compiler flags. This is traditionally called CFLAGS in makefiles.
+# Historically also available as %%{optflags}, and %%build sets the
+# environment variable RPM_OPT_FLAGS to this value.
+%build_cflags %{optflags}
+
ignatenkobrain commented on this pull request.
> +
+# C++ compiler flags. This is traditionally called CXXFLAGS in makefiles.
+%build_cxxflags %{optflags}
+
+# Fortran compiler flags. Makefiles use both FFLAGS and FCFLAGS as
+# the corresponding variable names.
+%build_fflags %{optflags}
pmatilai commented on this pull request.
> +
+# C++ compiler flags. This is traditionally called CXXFLAGS in makefiles.
+%build_cxxflags %{optflags}
+
+# Fortran compiler flags. Makefiles use both FFLAGS and FCFLAGS as
+# the corresponding variable names.
+%build_fflags %{optflags}
ignatenkobrain commented on this pull request.
> +
+# C++ compiler flags. This is traditionally called CXXFLAGS in makefiles.
+%build_cxxflags %{optflags}
+
+# Fortran compiler flags. Makefiles use both FFLAGS and FCFLAGS as
+# the corresponding variable names.
+%build_fflags %{optflags}
This is bascially a more elaborate version of #660 :
- Add language specific %build_fooflags macros to allow separate distro-wide
defaults for c, c++ and fortran
- Add %build_ldflags for specifying distro-wide ldflags (how on earth we didn't
have this?)
- Split FOOFLAGS= setting out of
Conan-Kudo approved this pull request.
Eh. I guess...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> But the main usage probably stopped when %GNUconfigure went away.
Ah of course. Thanks for pointing that out, it's actually good reason to get
rid of them: #691
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The only real users were in the unused %GNUconfigure macro which was
already removed in commit bb2cd52cf1067b9d18106f127a5034e2ad50db64 and
these should've gone with them.
This is a counter-proposal to #688
You can view, comment on, or merge this pull request online at:
pmatilai commented on this pull request.
>
find "$RPM_BUILD_ROOT" \! \( \
-name '*.pyo' -o -name '*.pyc' -o -name '*.elc' -o -name '.packlist' \
\) -type f -print0 | \
-LANG=C xargs -0r grep -F "$RPM_BUILD_ROOT" >$tmp
+LANG=C xargs -0r -P$NCPUS -n16 grep -F
That such a macro gets defined at all is merely rpm going "oh lookit, there's a
tag I know, lets define a corresponding macro for it". This is how %{name},
%{version} and all the other crud gets defined too.
I don't see how you could legitimately *use* the %buildarch macro for anything
at all
@pmatilai They are used in a few places and distros. But the main usage
probably stopped when `%GNUconfigure` went away. There's a `%autoreconfigure`
macro floating around somewhere that uses these as well...
--
You are receiving this because you are subscribed to this thread.
Reply to this
pmatilai approved this pull request.
Can't say I really grok the issue to begin with, but since there's a
verification from a heavy-duty user I dont see why not.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #690 into master.
--
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/690#event-2320472438___
Rpm-maint mailing list
Closed #685.
--
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/685#event-2320464453___
Rpm-maint mailing list
Closed #684.
--
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/684#event-2320465053___
Rpm-maint mailing list
> I would rather see all autofoo macro being removed...
Likewise. I've never seen any of those macros actually used, heck I didn't even
know we had such macros.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
35 matches
Mail list logo
