Bug 93687 - [PATCH] Split bsd.port.pre.mk - allow OPTIONS to be processed first
[PATCH] Split bsd.port.pre.mk - allow OPTIONS to be processed first
Status: Closed FIXED
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s)
Latest
Any Any
: Normal Affects Only Me
Assigned To: portmgr
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-22 02:30 UTC by shaun
Modified: 2006-11-22 20:50 UTC (History)
0 users

See Also:


Attachments
Mk.diff (1.67 KB, patch)
2006-02-22 02:30 UTC, shaun
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description shaun 2006-02-22 02:30:02 UTC
Please forgive me if I'm fiddling with something I shouldn't, or if I've
overlooked something obvious. The patch seems to work fine.

Currently, bsd.port[.pre].mk is used to process OPTIONS, which can then
be tested by a port. Unfortunately, the bsd.port.pre.mk is also used to
deal with other variables such as USE_OPENSSL and USE_RUBY. This
presents a catch-22 situation, because one cannot define USE_OPENSSL,
for instance, based on a choice made by the user in OPTIONS.

So, here is a possible solution, which - I hope - maintains existing
behavior for current ports, but allows porters to avoid using hacks to
get around the limitation.

The idea is to allow for something like this:
 
---------------------------------------------------------
PORTNAME=       someport
  ...
OPTIONS=        USE_SSL "Build with OpenSSL support" on
 
.include <bsd.port.options.mk>

.if defined(WITH_SSL)
USE_OPENSSL=            yes
.endif

.include <bsd.port.pre.mk>
  ...
---------------------------------------------------------

Presumably this would also need:

- bsd.port.options.mk in /usr/share/Mk
- Porter's Handbook documentation
Comment 1 Vasil Dimov freebsd_committer 2006-02-22 06:29:18 UTC
Responsible Changed
From-To: freebsd-ports-bugs->portmgr

portmgr territory
Comment 2 Mark Linimon freebsd_committer 2006-08-28 05:43:48 UTC
State Changed
From-To: open->analyzed

Accepted for testing on the cluster.
Comment 3 Mark Linimon freebsd_committer 2006-09-15 08:39:09 UTC
State Changed
From-To: analyzed->open

Due to linimon screwup, this was not tested as anticipated.  It will have to 
be rescheduled for after 6.2, now. 

fwiw, s/AFTERMKPORT/AFTERPORTMK/, so it might not have produced the correct 
result anyways.
Comment 4 Mark Linimon freebsd_committer 2006-09-20 13:46:40 UTC
State Changed
From-To: open->analyzed

Being tested on new cluster run.
Comment 5 dfilter freebsd_committer 2006-09-30 20:25:52 UTC
linimon     2006-09-30 19:25:46 UTC

  FreeBSD ports repository

  Modified files:
    Mk                   bsd.database.mk bsd.gcc.mk bsd.port.mk 
    math/elmer-mathlibs  Makefile 
    math/elmer-umfpack   Makefile 
    science/elmer-eio    Makefile 
    science/elmer-fem    Makefile 
    science/elmer-hutiter Makefile 
    science/elmer-matc   Makefile 
    science/elmerpost    Makefile 
  Log:
  * Split bsd.port.mk pre and post includes into 3 pieces instead of 2, to
    allow OPTIONS to be able to influence dependencies.  This is still
    experimental [1]
  
  * Teach bsd.gcc.mk about gfortran [2]
  
  * Remove the outdated emulators/linux_base; the new default has been
    linux_base-fc4.  This will allow the outdated port to be removed [3]
  
  * Add USE_FIREBIRD macros to bsd.database.mk [4]
  
  PR:     93687 [1], 93690 [2], 103184 [3], 103357 [4]
  
  Submitted by:   shaun [1], Pedro F. Giffuni <giffunip at asme to org> [2],
                  gerald [2], thierry [2], vd [3], skv [4]
  
  Revision  Changes    Path
  1.15      +31 -1     ports/Mk/bsd.database.mk
  1.9       +26 -8     ports/Mk/bsd.gcc.mk
  1.544     +21 -19    ports/Mk/bsd.port.mk
  1.7       +0 -2      ports/math/elmer-mathlibs/Makefile
  1.4       +0 -3      ports/math/elmer-umfpack/Makefile
  1.4       +0 -3      ports/science/elmer-eio/Makefile
  1.9       +1 -3      ports/science/elmer-fem/Makefile
  1.5       +1 -3      ports/science/elmer-hutiter/Makefile
  1.4       +0 -3      ports/science/elmer-matc/Makefile
  1.4       +1 -3      ports/science/elmerpost/Makefile
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 6 Mark Linimon freebsd_committer 2006-09-30 20:32:54 UTC
State Changed
From-To: analyzed->closed

Committed, thanks. 

Please let portmgr know when you are ready to try testing some ports that 
use this before committing.  We can do an incremental test on the cluster.
Comment 7 shaun 2006-11-22 15:17:28 UTC
On Sat, Sep 30, 2006 at 07:33:55PM +0000, Mark Linimon wrote:
> 
> Please let portmgr know when you are ready to try testing some ports that
> use this before committing.  We can do an incremental test on the cluster.
> 


In addition to the changes in the patch, there also needs to be a
bsd.port.options.mk entry in /usr/share/mk, because ${PORTSDIR} isn't
defined when the file is supposed to be included.

It has only just occurred to me that this could be quite problematic.
I'm not aware of any other way around this, besides adding:

  PORTSDIR?=	/usr/ports

to each port using bsd.port.options.mk.

-- 
Shaun Amott // PGP: 0x6B387A9A
"A foolish consistency is the hobgoblin
of little minds." - Ralph Waldo Emerson
Comment 8 kris 2006-11-22 20:39:43 UTC
On Wed, Nov 22, 2006 at 03:17:28PM +0000, Shaun Amott wrote:
> On Sat, Sep 30, 2006 at 07:33:55PM +0000, Mark Linimon wrote:
> > 
> > Please let portmgr know when you are ready to try testing some ports that
> > use this before committing.  We can do an incremental test on the cluster.
> > 
> 
> In addition to the changes in the patch, there also needs to be a
> bsd.port.options.mk entry in /usr/share/mk, because ${PORTSDIR} isn't
> defined when the file is supposed to be included.
> 
> It has only just occurred to me that this could be quite problematic.
> I'm not aware of any other way around this, besides adding:
> 
>   PORTSDIR?=	/usr/ports
> 
> to each port using bsd.port.options.mk.


Yeah, it's definitely going to need something more to work on systems
that aren't top-of-respective-branch.

Kris