rebuild pine... (fwd)

[Tomasz Kłoczko]

Seems Jeff Johnson can apply oure bcond macros or something similar. I
have no time for thin on Jeff reply.
On firs look seems Jeff have some valuable extesion for bcond.
Maybe someone have some comments for Jeff extending oure bcond scheme ?

---------- Forwarded message ----------
Date: Mon, 5 Feb 2001 12:01:57 -0500
From: Jeff Johnson <jbj at JBJ.ORG>
Reply-To: rpm-list at redhat.com
To: rpm-list at redhat.com
Subject: Re: rebuild pine...

On Mon, Feb 05, 2001 at 05:08:27PM +0100, Tomasz K?oczko wrote:
> On Sun, 4 Feb 2001, Tim Mooney wrote:
> 
> > In regard to: rebuild pine..., Christian Pearce said (at 9:02pm on Feb 2, 2001):
> > 
> > >I am trying to rebuild pine with noldap nokerberos and nossl.  I have
> > >spent the last two hours trying to figure this out.  Is it possiable.
> > >Reading the spec file
> > >
> > >%{!?nossl:BuildPrereq: openssl-devel}
> > >%{!?noldap:BuildPrereq: openldap-devel}
> > >%{!?nokerberos:BuildPrereq: krb5-devel}
> > >%{!?nokerberos:Requires: krb5-libs}
> > 
> > What happens if you add something like
> > 
> > 	--define nossl --define noldap --define nokerberos
> 
> BTW for PLD we prepare some kind simple but very smart and clean
> "infractructure" for contitional building which we names bcond macros.
> This allow build package using "--with <feacture>", "--without <feacture>"
> switches.
> 
> Modification is very small. In rpmpopt.in must be added:
> 
> rpm alias --with    --define "bcond_on_!#:+ 1"
> rpm alias --without --define "bcond_off_!#:+ 1"
> 
> and it allow use for example in spec header:
> 
> %{?bcond_on_ssl:BuildRequires: openssl-devel}
> %{?bcond_on_ldap:BuildRequires: openldap-devel}
> 
> and in %build:
> 
> %configure \
> 	%{?bcond_on_ssl:--with-ssl} \
> 	%{?bcond_off_ssl:--without-ssl} \
> 	%{?bcond_on_ldap:--with-ldap} \
> 	%{?bcond_off_ldap:--without-ldap}
> 
> And build by:
> 
> $ rpm -ba --with ssl --without ldap
> 

Nice, very nice, very very nice.

> Jeff IMHO it will be good include this to standard rpm. If You will aprove
> above I will send You all neccessary modyfications (it will be also good
> include few words for document bcond ;-).
> 

The only minor nitpicks I have are the arbitrary use of "bcond_" as
a prefix and 1 as a value.

How about overloading the autoconf option names as a mnemonic?

I'm thinking something like

(Note: Dunno whether the popt token "!#:+" can be reused like this,
I can certainly fix popt if necessary.)

...
rpmb alias --with    --define "_with_!#:+	--with-!#:+"
rpmb alias --without --define "_without_!#:+	--without-!#:+"
...
%{?_with_ssl:	BuildRequires: openssl-devel}}
%{?_with_ldap:	BuildRequires: openldap-devel}}
%{?_with_ssl:	BuildRequires: openssl-devel}}
%{?_with_ldap:	BuildRequires: openldap-devel}}
...
%configure \
    %{?_with_ssl:	%{_with_ssl}}	 \
    %{?_without_ssl:	%{_without_ssl}} \
    %{?_with_ldap:	%{_with_ldap}}	 \
    %{?_without_ldap:	%{_without_ldap}}

Using something other than 1 as a value for the macro might permit
piggy-backing other options opaquely, dunno whether that's a good idea
or not, as non-WYSWIG macro expansions could be a PITA.

I can also think of variants where "--with foo" would do
	%unglobal _without_foo
but I'd have to think carefully about CLI order vs. macro expansion ordering
issues. By this I mean that the definition for %_with_foo would look
something like
	%define _with_foo %{unglobal:_without_foo}--with-foo
so that the 1st expansion of _with_foo auto-magically removes _without_foo.
Hmmmm, makes my head hurt, simplicity is bliss.

Also, if %name (and/or %vendor, %arch, %os) was prepended to _with_foo et al,
the whole mess might even factor out of spec files into per-distro, per-package,
build system configuration, but that makes my head hurt even more.

Opinions? I'll add --with and --without to rpm popt config as soon as I can
detect consensus on proper usage of structured macro names etc for building.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj at jbj.org	(jbj at redhat.com)
Chapel Hill, NC



_______________________________________________
Rpm-list mailing list
Rpm-list at redhat.com
https://listman.redhat.com/mailman/listinfo/rpm-list