Date: Wed, 10 Oct 2012 20:35:36 +0100 From: Chris Rees <crees@FreeBSD.org> To: Michael Gmelin <freebsd@grem.de> Cc: freebsd-ports@freebsd.org Subject: Re: HAVE_GNOME vs. bsd.ports.options.mk Message-ID: <CADLo83_QzEHv4VR_ypO%2BZPWhRAVFJE91x180CBjud%2B4mdfb3kQ@mail.gmail.com> In-Reply-To: <20121010175248.19675251@bsd64.grem.de> References: <20121010121850.039fb6d2@bsd64.grem.de> <CADLo83-K%2Bi0rU9ssWuB8K9UTXRBa478UBBP1zrzChfAmtT5J%2Bw@mail.gmail.com> <20121010175248.19675251@bsd64.grem.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10 October 2012 16:52, Michael Gmelin <freebsd@grem.de> wrote:
> On Wed, 10 Oct 2012 16:40:39 +0100
> Chris Rees <utisoft@gmail.com> wrote:
>
>> On 10 Oct 2012 11:19, "Michael Gmelin" <freebsd@grem.de> wrote:
>> >
>> > Hi
>> >
>> > I noticed that HAVE_GNOME doesn't work properly with
>> > bsd.ports.options.mk yet, so
>> >
>> > .include <bsd.port.options.mk>
>> > .if ${HAVE_GNOME:Mgnomelibs}!=""
>> > # ...
>> > .endif
>> > .include <bsd.port.mk>
>> >
>> > won't work, while this
>> >
>> > .include <bsd.port.pre.mk>
>> > .if ${HAVE_GNOME:Mgnomelibs}!=""
>> > # ...
>> > .endif
>> > .include <bsd.port.post.mk>
>> >
>> > does.
>> >
>> > AFAIK bsd.port.pre.mk/bsd.port.post.mk should be replaced by
>> > bsd.port.options.mk/bsd.port.mk in the long term, so having this
>> > work or documenting a workaround would help port maintainers who are
>> > in the process of updating the port structure.
>>
>> No. They are two separate methods with two different reasons for
>> using them.
>>
>> You have discovered a case of pre.mk being the correct one to use,
>> which is unusual :)
>>
>> Chris
>> _______________________________________________
>> freebsd-ports@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to
>> "freebsd-ports-unsubscribe@freebsd.org"
>
> In which case the Porter's Handbook gives little to no advice what the
> actual differences are.
>
> The only time bsd.port.options.mk is mentioned is in the context of
> OptionsNG (5.12.2.2) where it says:
>
> "OPTIONS definitions must appear before the inclusion of
> bsd.port.options.mk. The PORT_OPTIONS variable can only be tested after
> the inclusion of bsd.port.options.mk. Inclusion of bsd.port.pre.mk can
> be used instead, too, and is still widely used in ports written before
> the introduction of bsd.port.options.mk. But be aware that some
> variables will not work as expected after the inclusion of
> bsd.port.pre.mk, typically some USE_* flags."
>
> Which sounds to me like: "Yes, you can still use bsd.port.pre.mk, but
> it's the old way of doing things and expect bad things to happen."
>
> It would probably make sense to refine that section in the Porter's
> Handbook - I know that this is a moving target right now, but since it
> is it either needs to be adapted or at least fact that this is the case
> should be stated somewhere (potentially with a link to the wiki).
>
> I would be willing to propose a refined version of this section in the
> Porter's Handbook - might take me a while though since I'm pretty busy
> at the moment. But if nobody else has the resources I would do it myself
> for the sake of making things easier for maintainers.
>
I'm afraid this archive is full of "This should be in the Porter's
Handbook" suggestions-- you're absolutely right, but Someone (tm)
needs to write that section-- it's very kind of you to volunteer :)
There are always going to be weird subtleties.
In a nutshell;
bsd.port.pre.mk USED to be used for:
- Defining ARCH, PREFIX, etc for testing
- Defining WITH_/WITHOUT_ etc for testing from OPTIONS.
bsd.port.options.mk now performs these stages.
The use for bsd.port.pre.mk is for testing variables defined in
Mk/bsd.*.mk if a USE_ variable has been defined.
USE_EMACS= yes
.include <bsd.port.pre.mk>
.if ${EMACS_VER} > 20.6
# do something
.endif
I can't think of any other circumstances where pre.mk is required--
anyone is free to correct me.
The upshot is that bsd.port.pre.mk is rarely required nowadays, since
bsd.port.options.mk defines most things and has fewer nasty side
effects. However, there are still unusual cases such as the one I
just mentioned; both need to be kept. I have a nice rant about the
craziness there at [1], but bear in mind there are lots of rough edges
and it needs reworking if any of it needs implementing.
Chris
[1] http://wiki.freebsd.org/SimplifyingMkIncludes
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLo83_QzEHv4VR_ypO%2BZPWhRAVFJE91x180CBjud%2B4mdfb3kQ>