Building port with options

Alejandro Pulver alejandro at varnet.biz
Fri Feb 25 09:10:45 PST 2005


On Tue, 22 Feb 2005 23:37:12 +0200
Peter Pentchev <roam at ringlet.net> wrote:

> 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 at ringlet.net> wrote:
> > 
> > > On Sat, Feb 19, 2005 at 03:06:41PM -0300, Alejandro Pulver wrote:
> > > > Hello,
> > > > 
> > > > 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.
> > > > 
> > > > I also tried 'WANT_GNOME' before including 'bsd.ports.pre.mk'
> > > > and'USE_GNOME' instead of 'WITH_GNOME'.
> > > > 
> > > > What am I doing wrong?
> > > 
> > > Nothing; that's the way things are supposed to work :)
> > > 
> > > 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 :)
> > 
> > Thanks for your reply.
> > 
> > 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
> 
> -- 
> Peter Pentchev	roam at ringlet.net    roam at cnsys.bg    roam at 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.
> 

Thank You.

That helped me a lot.

How can I define a variable in gmake from the port's
Makefile (gmake(1) says with environment variables and '-e')?

If a port uses TCL/TK, how can I define it (I have TCL/TK 8.4/8.0 but it
outputs the following):

checking tcl8.0.h usability... no
checking tcl8.0.h presence... no
checking for tcl8.0.h... no
checking tk8.0.h usability... no
checking tk8.0.h presence... no
checking for tk8.0.h... no

Is there a port that uses TCL/TK and has the same issue (but solved)?

Thanks and Best Regards,
Ale


More information about the freebsd-ports mailing list