Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Feb 2005 23:37:12 +0200
From:      Peter Pentchev <roam@ringlet.net>
To:        Alejandro Pulver <alejandro@varnet.biz>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: Building port with options
Message-ID:  <20050222213712.GA799@straylight.m.ringlet.net>
In-Reply-To: <20050222174715.7f11612c@ale.varnet.bsd>
References:  <20050219150641.43dd175f@ale.varnet.bsd> <20050222152607.GI805@straylight.m.ringlet.net> <20050222174715.7f11612c@ale.varnet.bsd>

next in thread | previous in thread | raw e-mail | index | archive | help

--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 22, 2005 at 05:47:15PM -0300, Alejandro Pulver wrote:
> On Tue, 22 Feb 2005 17:26:07 +0200
> Peter Pentchev <roam@ringlet.net> wrote:
>=20
> > On Sat, Feb 19, 2005 at 03:06:41PM -0300, Alejandro Pulver wrote:
> > > Hello,
> > >=20
> > > I am making a port of an application that allows to build with the
> > > following options:
[snip]
> > > I can build it with all (3) the combinations (make -DWITH_*), but when
> > > the build terminates, I change the option "-D" to compile a different
> > > version, but it does nothing. So I have to 'make clean' or 'rm -rf
> > > work' before compiling with a different option.
> > >=20
> > > I also tried 'WANT_GNOME' before including 'bsd.ports.pre.mk' and
> > > 'USE_GNOME' instead of 'WITH_GNOME'.
> > >=20
> > > What am I doing wrong?
> >=20
> > Nothing; that's the way things are supposed to work :)
> >=20
> > That's the way that the 'fetch', 'extract', 'patch', 'configure', 'all',
> > and 'install' targets behave - after their work is done, they touch a
> > file in the work/ directory, and they actually depend on this file.  You
> > can see these files with a 'ls -A work/' - there should be files with
> > names like ".extract_done.generator-cbiere-1.0._usr_local".  If such a
> > file exists, 'make extract' will do nothing, since make(1) will know
> > that the 'extract' target has already been fulfilled.
[snip]
> > In short, the only way for the Ports framework to be *sure* that it has
> > a clean environment to build the port with the new options is to, well,
> > provide a really clean environment - remove the WRKSRC directory
> > whatsoever, and redo the full extract/patch/configure/build cycle from
> > scratch.  That's basically what 'make clean' does, and that's what 'rm
> > -rf work' effectively does, as you have discovered :)
>=20
> Thanks for your reply.
>=20
> I was confused with the port of Vim, that uses different variables to
> pass the options (but I think it depends on the Vim build environment).

Yes, it depends on the build environment, *and* on the install
environment.  Since the dependencies are affected by the environment,
the *same* environment (or make) variables have to be set during the
build and install stage.  Actually, they have to be set during the
package stage, too, if you are doing a 'make package', and sometimes it
would be good to have them set during 'make clean', too, if some of the
dependencies did not exist previously and was built during the build of
this port, but this is not mandatory.

> So the port is just fine?

Yep.

> I mean: Do I have to implement extra steps to make 'make' notice the
> changes?

No.  Just do a 'make clean' after each 'make' when you need to change
the options, and don't forget to pass the *same* options to 'make
install' when you get round to it.

> Can you please mention some ports that use build options?

Yes, take a look at ports/security/apg/Makefile - it honors the
WITH_CRACKLIB variable.  If it is set, then security/cracklib is added
to the build dependencies (so WITH_CRACKLIB should be set as early as
'make configure') and also the -DWITH_CRACKLIB is added to the MAKE_ARGS
variable, which is passed to the actual apg Makefile during the 'all'
stage (so WITH_CRACKLIB should *also* be set during 'make all').

Also, take a look at ports/textproc/texi2html/Makefile and pkg-plist.
If the PROGRAM_PREFIX variable is defined to a non-empty value, then an
additional --program-prefix argument is passed to texi2html's configure
script.  Later, at install time, when the pkg-plist file is processed,
if PROGRAM_PREFIX is defined, then the PLIST_SUB variable says that the
%%PROGRAM_PREFIX%% part of the bin/texi2html line should be substituted
%with the contents of the PROGRAM_PREFIX variable.  Thus, PROGRAM_PREFIX
should be defined at both configure and install time; in this case, it
has no bearing on the 'all' target itself, since the configure script
has already "heard" about the requested change.

Hope that helps :)

G'luck,
Peter

--=20
Peter Pentchev	roam@ringlet.net    roam@cnsys.bg    roam@FreeBSD.org
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
This sentence is false.

--9amGYk9869ThD9tj
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)

iD8DBQFCG6YI7Ri2jRYZRVMRAq0mAKCIf09PLNnCanRaNLnJ/x3OQPc+aQCgrSxN
qfA1WW3xmGrPtpTsYwYvJ9M=
=cE0D
-----END PGP SIGNATURE-----

--9amGYk9869ThD9tj--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050222213712.GA799>