#551 is relevant/related.
--
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/860#issuecomment-542613820___
Rpm-maint mailing list
I've been mulling over this thing over and over: in principle, I like the idea
of eliminating magic from %setup a lot, I've just been worried that there are
cases that our test-suite doesn't exhibit that rely on some subtleties around
spec->buildSubdir being untouchable by macros (maybe because
Just submitted #890 to sanitize + fix the build-in-place case, which should
eliminate it from the radar in this patch completely.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
pmatilai commented on this pull request.
> @@ -345,7 +349,7 @@ static int doSetupMacro(rpmSpec spec, const char *line)
}
if (!createDir) {
- rasprintf(, "cd '%s'", spec->buildSubdir);
+ buf = rpmExpand("%{?buildsubdir:cd '%{buildsubdir}'}", NULL);
As an aside, the
pmatilai commented on this pull request.
> @@ -345,7 +349,7 @@ static int doSetupMacro(rpmSpec spec, const char *line)
}
if (!createDir) {
- rasprintf(, "cd '%s'", spec->buildSubdir);
+ buf = rpmExpand("%{?buildsubdir:cd '%{buildsubdir}'}", NULL);
I mean, this is inside
pmatilai commented on this pull request.
> @@ -345,7 +349,7 @@ static int doSetupMacro(rpmSpec spec, const char *line)
}
if (!createDir) {
- rasprintf(, "cd '%s'", spec->buildSubdir);
+ buf = rpmExpand("%{?buildsubdir:cd '%{buildsubdir}'}", NULL);
We didn't need all
pmatilai commented on this pull request.
> }
/* Mer addition - support --build-in-place */
if (rpmExpandNumeric("%{_build_in_place}")) {
buildInPlace = 1;
- spec->buildSubdir = NULL;
+ rpmPushMacro(spec->macros, "buildsubdir", NULL, "", RMIL_SPEC);
This would
> %buildsubdir is a long-standing documented macro, we can't just rename it on
> a whim as doing so will break packages that were doing nothing wrong.
Okay, I didn't realize that, but the renaming part is only there because I
thought the codebase didn't like to expose non-underscored globals.
%buildsubdir is a long-standing documented macro, we can't just rename it on a
whim as doing so will break packages that were doing nothing wrong.
What's the actual use-case behind this?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
nwnk approved this pull request.
> @@ -329,8 +333,8 @@ static int doSetupMacro(rpmSpec spec, const char *line)
/* if necessary, create and cd into the proper dir */
if (createDir) {
- buf = rpmExpand("%{__mkdir_p} ", spec->buildSubdir, "\n",
- "cd '",
@vathpela pushed 1 commit.
43c0982a97a5c600f00b8108ef1765bc15ee563f Make %{buildsubdir} usable without
being a side effect of %setup.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
> Other than the typo this looks good to me.
>
> `Reviewed-by: Adam Jackson `
Yeah, that's what I get for doing make check and then going "oh that looks
dangerous, but it's an easy fix" while re-reading the patch before pushing.
Anyway, new version that passes pushed.
--
You are receiving
Other than the typo this looks good to me.
`Reviewed-by: Adam Jackson `
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This patch makes a couple of related changes:
- lets you set %{_buildsubdir} as a global to expose it everywhere,
rather than just specific parts of %prep (%setup and %patch*)
- lets you choose what path is used independently of the unpack
options in %setup
- allows you to use a different
14 matches
Mail list logo
