On Fri, Feb 01, 2008, Jeff Johnson wrote:

> On Feb 1, 2008, at 10:15 AM, Stefan Westmeier wrote:
>
>     Thx !! Works :-)
>     One observation I made:
>     in my macros file (/home/user/SWDev/rpmmacros) I define:
>
>         %_builddir       %{wa_root}
>
>     rpmbuild --macros /opt/lib/rpm/macros:/home/user/SWDev/rpmmacros \
>                      --define 'wa_root /home/user/SWDev' --eval '%{_builddir}
>     --> /home/user/SWDev
>
>     rpmbuild --define 'wa_root /home/user/SWDev' \
>                    --macros /opt/lib/rpm/macros:/home/user/SWDev/rpmmacros
>     --eval '%{_builddir}
>     --> /opt/src/rpm/BUILD
>
>     Is this a bug or a feature ?
>
> There's order implicit in how macros are defined.
>
> I can't tell atm bug <-> feature because of current/recent changes
> to macro processing. Its not like rpm's macro handling is defined
> in some standard.
>
> Traditionally, rpm attempted initialization -> CLI defines -> spec file defines
> in that order, so I'd say bug. But additional (and useful) functionality added
> for OpenPKG may prevent the traditional goal in rpm-5.0.
>
> You should get deterministic behavior if you add --macro before any
> --define.

The difference is _not_ related to any recent changes AFAIK.

The difference just exists because "--macros" is effectively ignored
if it comes after one of many options, including "--define", which
implicitly trigger the CLI initialization which in turn loads (BUT
ONLY ONCE!) the set of configured macro files. So, a "--define" first
implicitly loads the default macro files and hence the "--macros" option
afterwards still overrides the set of configured macro files, but the
files are never really loaded again. And I also do not recommend to
load them again as such an approach caused us headages in the Apache
webserver the whole last decade.

So, I would say it is neither a bug nor a feature. It is an obscurity
caused by the fact that RPM interleaves option parsing and option
processing. For mostly all options it doesn't matter, but for --macros,
--defines and --eval it matters. And unfortunately, those three options
are exactly what you used.

So, the recommended order of options is:

    1. --macros
    2. --define
    3. --eval
    4. anything else

But nevertheless I think RPM should at least detect a misodering and
give out a warning...

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com