On Fri, Feb 01, 2008, Ralf S. Engelschall wrote:

> 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.

Remains one question: why does --define perform the rpmcliConfigured()
at all? I've currently no clue...

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