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>