Re: Timing problem with '%buildsubdir'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


It's because the way how parsePrep() is implemented. First it reads all lines
in %prep section (parsePrep.c:545,555) during this process all macros are
expanded and then it looks for %setup in these read lines (parsePrep.c:557,569)
and if it finds it, function doSetup() is executed. So doSetup() is executed
and macro %buildsubdir is defined after all macros in %prep section are 

So I think that it behaves as it behaves only because the way how it is
implemented. I don't think that there is some rule that the macro %buildsubdir 
shouldn't be defined in %prep section.


----- Original Message -----
> From: "Andreas Scherer" <andreas.scherer@xxxxxxxx>
> To: rpm-list@xxxxxxxxxxxxx
> Sent: Sunday, January 31, 2016 10:27:45 AM
> Subject: Timing problem with '%buildsubdir'
> Hash: SHA1
> Why is macro '%buildsubdir' not available in section '%prep'?
> According to the comment in 'macros[.in]', '%buildsubdir' is "set
> after processing %setup", but there seems to be a timing problem in
> setting and resolving this particular item.
>    %prep
>    %setup -c
>    %{echo:<<<PREP:%buildsubdir>>>}
> produces "<<<PREP:%buildsubdir>>>, i.e., the macro is _not_ set at
> this point, while a later
>    %build
>    %{echo:<<<BUILD:%buildsubdir>>>}
> produces the expected <<<BUILD:sgb-20090810>>>. (Using
> '' as example.)
> Internally, 'doSetupMacro()' uses 'spec->buildSubdir' for referencing
> the project building area, and calls 'addMacro(...,"buildsubdir",...)'
> on the way.
> Version: GnuPG v2.0.22 (GNU/Linux)
> iEYEARECAAYFAlat05EACgkQpGC+y3YKfI7dJgCfZmS9W7s1MksR2y3ZfXUrjXjS
> B6oAnA21/czC0HvLMO5dQ4Ejj/1e6Z2Y
> =3VC6
> _______________________________________________
> Rpm-list mailing list
> Rpm-list@xxxxxxxxxxxxx
Rpm-list mailing list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux