Re: UID/GID_OFFSET (Was: Re: WITH_GCC)
On 12-6-2012 2:38, Warren Block wrote:
On Fri, 25 May 2012, Mel Flynn wrote:
On 20-5-2012 14:06, Chris Rees wrote:
Usually. Sometimes it's (ab)used to include the relevant bsd.*.mk
file without adding dependencies (WANT_GNOME), but normally that's
what WANT_ is used for.
Definitely add a warning that if you want to use a WANT_ variable you
should also check the relevant Mk/ files to check for syntax.
What's also not consistent is the use of:
USE_FOO=42+
which is shorthand for:
USE_FOO=yes
WANT_FOO_VER=42+
Anyway, since Warren is on the job, on one of my travels through pmk, I
turned a corner and met these totally awesome user settable variables:
UID_OFFSET
GID_OFFSET
No docs on them in pmk itself or share/examples/etc/make.conf. What they
do is add the specified number to the UID and GID that a port defines by
using /usr/ports/{UIDS,GIDS}. This is extremely useful if you are using
multiple jails on one machine and don't want the uid's to clash (shared
memory for example).
It's also useful, if you have different providers for uid/gid
information through the use of NSS modules. Knowing that ports won't
ever get into your module range makes you sleep better.
Example in /etc/make.conf
UID_OFFSET=2
GID_OFFSET=${UID_OFFSET} # best to keep them equal
Installing for example postgresql, will now use uid/gid 20070 instead
of 70.
Okay, I've finally cleared some room to work on this; sorry about the
delay.
My main question is where to add these descriptions. Should they go in
existing sections where possible? Or are we talking about a new
section, and if so, where? At the end of the Dependencies section?
Ideally in man7/ports.7, but I see that is quite outdated. It shouldn't
be in the porters handbook. The variables are useful for end users. The
handbook maybe?
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: UID/GID_OFFSET (Was: Re: WITH_GCC)
On Wed, 13 Jun 2012, Mel Flynn wrote:
On 12-6-2012 2:38, Warren Block wrote:
On Fri, 25 May 2012, Mel Flynn wrote:
On 20-5-2012 14:06, Chris Rees wrote:
Usually. Sometimes it's (ab)used to include the relevant bsd.*.mk
file without adding dependencies (WANT_GNOME), but normally that's
what WANT_ is used for.
Definitely add a warning that if you want to use a WANT_ variable you
should also check the relevant Mk/ files to check for syntax.
What's also not consistent is the use of:
USE_FOO=42+
which is shorthand for:
USE_FOO=yes
WANT_FOO_VER=42+
Anyway, since Warren is on the job, on one of my travels through pmk, I
turned a corner and met these totally awesome user settable variables:
UID_OFFSET
GID_OFFSET
No docs on them in pmk itself or share/examples/etc/make.conf. What they
do is add the specified number to the UID and GID that a port defines by
using /usr/ports/{UIDS,GIDS}. This is extremely useful if you are using
multiple jails on one machine and don't want the uid's to clash (shared
memory for example).
It's also useful, if you have different providers for uid/gid
information through the use of NSS modules. Knowing that ports won't
ever get into your module range makes you sleep better.
Example in /etc/make.conf
UID_OFFSET=2
GID_OFFSET=${UID_OFFSET} # best to keep them equal
Installing for example postgresql, will now use uid/gid 20070 instead
of 70.
Okay, I've finally cleared some room to work on this; sorry about the
delay.
My main question is where to add these descriptions. Should they go in
existing sections where possible? Or are we talking about a new
section, and if so, where? At the end of the Dependencies section?
Ideally in man7/ports.7, but I see that is quite outdated. It shouldn't
be in the porters handbook. The variables are useful for end users. The
handbook maybe?
I understood this to be definitions of the WITH_, USE_, and WANT_
variables in the Porter's Handbook to help maintainers understand when
they should use which style. The UID/GID_OFFSET variables should
possibly be a separate thing.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: UID/GID_OFFSET (Was: Re: WITH_GCC)
On Fri, 25 May 2012, Mel Flynn wrote:
On 20-5-2012 14:06, Chris Rees wrote:
Usually. Sometimes it's (ab)used to include the relevant bsd.*.mk
file without adding dependencies (WANT_GNOME), but normally that's
what WANT_ is used for.
Definitely add a warning that if you want to use a WANT_ variable you
should also check the relevant Mk/ files to check for syntax.
What's also not consistent is the use of:
USE_FOO=42+
which is shorthand for:
USE_FOO=yes
WANT_FOO_VER= 42+
Anyway, since Warren is on the job, on one of my travels through pmk, I
turned a corner and met these totally awesome user settable variables:
UID_OFFSET
GID_OFFSET
No docs on them in pmk itself or share/examples/etc/make.conf. What they
do is add the specified number to the UID and GID that a port defines by
using /usr/ports/{UIDS,GIDS}. This is extremely useful if you are using
multiple jails on one machine and don't want the uid's to clash (shared
memory for example).
It's also useful, if you have different providers for uid/gid
information through the use of NSS modules. Knowing that ports won't
ever get into your module range makes you sleep better.
Example in /etc/make.conf
UID_OFFSET= 2
GID_OFFSET= ${UID_OFFSET} # best to keep them equal
Installing for example postgresql, will now use uid/gid 20070 instead of 70.
Okay, I've finally cleared some room to work on this; sorry about the
delay.
My main question is where to add these descriptions. Should they go in
existing sections where possible? Or are we talking about a new
section, and if so, where? At the end of the Dependencies section?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
UID/GID_OFFSET (Was: Re: WITH_GCC)
On 20-5-2012 14:06, Chris Rees wrote:
Usually. Sometimes it's (ab)used to include the relevant bsd.*.mk
file without adding dependencies (WANT_GNOME), but normally that's
what WANT_ is used for.
Definitely add a warning that if you want to use a WANT_ variable you
should also check the relevant Mk/ files to check for syntax.
What's also not consistent is the use of:
USE_FOO=42+
which is shorthand for:
USE_FOO=yes
WANT_FOO_VER= 42+
Anyway, since Warren is on the job, on one of my travels through pmk, I
turned a corner and met these totally awesome user settable variables:
UID_OFFSET
GID_OFFSET
No docs on them in pmk itself or share/examples/etc/make.conf. What they
do is add the specified number to the UID and GID that a port defines by
using /usr/ports/{UIDS,GIDS}. This is extremely useful if you are using
multiple jails on one machine and don't want the uid's to clash (shared
memory for example).
It's also useful, if you have different providers for uid/gid
information through the use of NSS modules. Knowing that ports won't
ever get into your module range makes you sleep better.
Example in /etc/make.conf
UID_OFFSET= 2
GID_OFFSET= ${UID_OFFSET} # best to keep them equal
Installing for example postgresql, will now use uid/gid 20070 instead of 70.
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: WITH_GCC
On 20 May 2012 06:18, Warren Block wbl...@wonkity.com wrote: On Wed, 16 May 2012, Mark Linimon wrote: On Fri, May 11, 2012 at 12:10:25AM +0300, Andriy Gapon wrote: P.S. Perhaps this information should also be somewhere in the Porter's Handbook. It is scattered around in it: WITH/WITHOUT: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-options.html#AEN2542 USE: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-depend.html#USE-VARS Unfortunately WANT is only documented in bsd.port.mk itself. Does anyone wish to take on the task of adding a tips-and-tricks entry about the difference between the 3 to the PH? http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk?annotate=1.708 (line 285) Okay, I'll bite. However, I missed the earlier part of the thread and the descriptions of the USE and WANT options weren't very clear to me. Also I'm not sure where the text should go in the PH. Other than that, it's quite clear. Maybe: WITH_ and WITHOUT_ variables may be set by the port maintainer as defaults, and modified by the end user as configuration options. Example: WITHOUT_X11= yes This is about to be phased out in favour of optionsng. I would seriously consider whether a revision of the docs is worth it until optionsNG is committed some time fairly soon. USE_ variables are set by the port maintainer to define software on which this port depends. Example: USE_BZIP2= yes Yes. WANT_ variables are set by the port maintainer to prefer one version or variation of a dependency over another. Examples: WANT_OPENLDAP_VER= 23 WANT_BDB_VER= 48 WANT_PGSQL_VER= 90 WANT_PHP_WEB= yes Usually. Sometimes it's (ab)used to include the relevant bsd.*.mk file without adding dependencies (WANT_GNOME), but normally that's what WANT_ is used for. Definitely add a warning that if you want to use a WANT_ variable you should also check the relevant Mk/ files to check for syntax. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: WITH_GCC
On Wed, 16 May 2012, Andriy Gapon wrote:
+CFLAGS+= ${CFLAGS.${CC}}
+CXXFLAGS+= ${CXXFLAGS.${CC}}
Similarly here. Where does this come from, why is it related to
the WITH_GCC versus USE_GCC patch? Can and should this be split
out? How is it used and where? Where is it defined?
This should be split out. The use case is to make it possible to set
something like the following in make.conf:
CFLAGS.gcc46+= -fearlier-gcc-fails-with-this-flag-but-I-want-it-with-gcc46
I see! The only question I have is whether, given there is also clang,
this is really best suited for Mk/bsd.gcc.mk, or this should rather
become part of the general Mk/bsd.port.mk?
To me it looks more like the latter, Mk/bsd.port.mk, but if not for
some reason, please add a comment to the top of the file Mk/bsd.gcc.mk
and commit this part.
Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: WITH_GCC
On Wed, 16 May 2012, Mark Linimon wrote: On Fri, May 11, 2012 at 12:10:25AM +0300, Andriy Gapon wrote: P.S. Perhaps this information should also be somewhere in the Porter's Handbook. It is scattered around in it: WITH/WITHOUT: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-options.html#AEN2542 USE: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-depend.html#USE-VARS Unfortunately WANT is only documented in bsd.port.mk itself. Does anyone wish to take on the task of adding a tips-and-tricks entry about the difference between the 3 to the PH? http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk?annotate=1.708 (line 285) Okay, I'll bite. However, I missed the earlier part of the thread and the descriptions of the USE and WANT options weren't very clear to me. Also I'm not sure where the text should go in the PH. Other than that, it's quite clear. Maybe: WITH_ and WITHOUT_ variables may be set by the port maintainer as defaults, and modified by the end user as configuration options. Example: WITHOUT_X11= yes USE_ variables are set by the port maintainer to define software on which this port depends. Example: USE_BZIP2=yes WANT_ variables are set by the port maintainer to prefer one version or variation of a dependency over another. Examples: WANT_OPENLDAP_VER=23 WANT_BDB_VER= 48 WANT_PGSQL_VER= 90 WANT_PHP_WEB= yes ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: WITH_GCC
On Fri, May 11, 2012 at 12:10:25AM +0300, Andriy Gapon wrote: P.S. Perhaps this information should also be somewhere in the Porter's Handbook. It is scattered around in it: WITH/WITHOUT: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-options.html#AEN2542 USE: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-depend.html#USE-VARS Unfortunately WANT is only documented in bsd.port.mk itself. Does anyone wish to take on the task of adding a tips-and-tricks entry about the difference between the 3 to the PH? http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk?annotate=1.708 (line 285) mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: WITH_GCC
Hi Andriy,
Mark Linimon worked on a similar patchset in the past. Have the
two of you synced and shared patches? I did review some of his
a bit ago, and while I do not have that any more, I believe it
was somewhat different than your approach.
I'll provide some comments below. Note, I am not opposed to the
patch, but feel it may be better broken up in distinct and independent
changes. Some should go through a full cluster build. And some
give me serious headache.
On Fri, 11 May 2012, Andriy Gapon wrote:
Hopefully it should handle the bootstrapping better by accounting for
lang/gcc*
ports dependencies and avoiding creating any circular dependencies.
For simplicity the GCC ports and their dependencies are forced to be
built with the base GCC, although this does not have to be required.
Looking at the patch, there is no documentation. Can you please add
some comments to document the new setting and how it interacts with
what is in place as of today?
+.if defined(WITH_GCC) ${PORTNAME} != gcc
+
+# See if we can use a later version or exclusively the one specified.
+_WITH_GCC:= ${WITH_GCC:S/+//}
Shouldn't there first be some code that handles the case where USE_GCC
and WITH_GCC are specified at the same time?
Also, is this duplication of code really necessary between the two
settings, or could that be avoided by setting USE_GCC appropriately
under the right conditions (if and only if...) or something like
that?
.if defined(_GCC_ORLATER)
+. if defined(_WITH_GCC)
+. if ${_USE_GCC} ${_WITH_GCC}
+_USE_GCC:= ${_WITH_GCC}
+. endif
+. endif
When can this happen? And can this be handled earlier, cf. above?
-_GCC_BUILD_DEPENDS:= gcc${V}
_GCC_PORT_DEPENDS:= gcc${V}
+. if ${V} == ${GCC_DEFAULT_V}
+_GCC_BUILD_DEPENDS:= gcc
+. else
+_GCC_BUILD_DEPENDS:= gcc${V}
+. endif
Isn't this an unrelated change to what you are mainly working on?
I'd prefer to avoid that, unless there is a good reason. And if
there is, I'm open (and like) to see this go in separately.
+_GCC_OWN_DEPENDS!= (cd ${PORTSDIR}/lang/${_GCC_BUILD_DEPENDS} ${MAKE} -V
_UNIFIED_DEPENDS)
+. for _CURDIR in ${.CURDIR} # only loop variable are expanded in variable
modifiers
+. if ${_GCC_OWN_DEPENDS:M*\:${_CURDIR}} !=
+.undef _GCC_BUILD_DEPENDS
+.undef _GCC_PORT_DEPENDS
+. else
Headache, major headache. :-) What is this for, do we really need
it, and why, and can this be done differently?
+CFLAGS+= ${CFLAGS.${CC}}
+CXXFLAGS+= ${CXXFLAGS.${CC}}
Similarly here. Where does this come from, why is it related to
the WITH_GCC versus USE_GCC patch? Can and should this be split
out? How is it used and where? Where is it defined?
Gerald
PS: I won't be able to do FreeBSD work the coming two weeks (at all,
probably) but am very open to working with you and this change or
changes split out of that as well as other changes. Do not read
anything into it if responses may take a bit at times. :-)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: WITH_GCC
on 16/05/2012 04:35 Gerald Pfeifer said the following:
Hi Andriy,
Mark Linimon worked on a similar patchset in the past. Have the
two of you synced and shared patches? I did review some of his
a bit ago, and while I do not have that any more, I believe it
was somewhat different than your approach.
Yes. While I tried only to add support for requesting a different version of
GCC, Mark is also adding support for a different compiler altogether (clang).
Mark's patch is also more comprehensive in other aspects (e.g. WANT_GCC).
We are looking at each other's changes :-)
I'll provide some comments below. Note, I am not opposed to the
patch, but feel it may be better broken up in distinct and independent
changes. Some should go through a full cluster build. And some
give me serious headache.
On Fri, 11 May 2012, Andriy Gapon wrote:
Hopefully it should handle the bootstrapping better by accounting for
lang/gcc*
ports dependencies and avoiding creating any circular dependencies.
For simplicity the GCC ports and their dependencies are forced to be
built with the base GCC, although this does not have to be required.
Looking at the patch, there is no documentation. Can you please add
some comments to document the new setting and how it interacts with
what is in place as of today?
I think that I provided that in one of my earlier emails. You are correct that
it should go in as a documentation comment.
But at the moment, here it is for the reference:
[quote]
The idea behind the patch:
- if WITH_GCC is not defined, then everything should be as before
- if WITH_GCC is defined, but USE_GCC is not defined, then USE_GCC gets set
from WITH_GCC and then everything should be handled as before
- if both are defined
o if USE_GCC is a concrete version, then it wins
o else (if USE_GCC has the X+) form, then the minimum requested version
becomes MAX(X, Y), where Y is from WITH_GCC [*]
[*] Note that whether WITH_GCC has Y or Y+ form doesn't matter in this case.
In all cases WITH_GCC can be used only to increase minimum required GCC version,
unless a port wants a concrete fixed version.
[/quote]
+.if defined(WITH_GCC) ${PORTNAME} != gcc
+
+# See if we can use a later version or exclusively the one specified.
+_WITH_GCC:= ${WITH_GCC:S/+//}
Shouldn't there first be some code that handles the case where USE_GCC
and WITH_GCC are specified at the same time?
My approach is different:
- first validate that WITH_GCC has a sane value
- set USE_GCC if it is not set but WITH_GCC is set
Only after these steps I try to handle the case where both knobs are set
(according to the logic described at the beginning).
Also, is this duplication of code really necessary between the two
settings, or could that be avoided by setting USE_GCC appropriately
under the right conditions (if and only if...) or something like
that?
The code duplication is not nice, agreed. But I do not see what you suggest.
There are two different variables with a value in the same format, both could be
set at the same time, they could be set to different values, both need to be
validated.
.if defined(_GCC_ORLATER)
+. if defined(_WITH_GCC)
+. if ${_USE_GCC} ${_WITH_GCC}
+_USE_GCC:= ${_WITH_GCC}
+. endif
+. endif
When can this happen? And can this be handled earlier, cf. above?
This is the case when e.g. a port has USE_GCC=4.2+ and a user specifies
WITH_GCC=4.6+. I can't see how this case can be handled earlier, but I wouldn't
rule out that it could be possible.
-_GCC_BUILD_DEPENDS:=gcc${V}
_GCC_PORT_DEPENDS:= gcc${V}
+. if ${V} == ${GCC_DEFAULT_V}
+_GCC_BUILD_DEPENDS:=gcc
+. else
+_GCC_BUILD_DEPENDS:=gcc${V}
+. endif
Isn't this an unrelated change to what you are mainly working on?
Yes. I locally preferred that gcc 4.6 dependency is handled by lang/gcc instead
of lang/gcc46 when neither is installed yet.
I'd prefer to avoid that, unless there is a good reason. And if
there is, I'm open (and like) to see this go in separately.
I am not sure if it could be considered a good reason, but lang/gcc seems to be
more stable and thus user-friendlier. But yes, the snippet should be excluded
from this patch.
+_GCC_OWN_DEPENDS!= (cd ${PORTSDIR}/lang/${_GCC_BUILD_DEPENDS} ${MAKE} -V
_UNIFIED_DEPENDS)
+. for _CURDIR in ${.CURDIR} # only loop variable are expanded in variable
modifiers
+. if ${_GCC_OWN_DEPENDS:M*\:${_CURDIR}} !=
+.undef _GCC_BUILD_DEPENDS
+.undef _GCC_PORT_DEPENDS
+. else
Headache, major headache. :-) What is this for, do we really need
it, and why,
This is done to handle dependencies of a gcc port itself.
An example. Current lang/gcc46 has the following:
LIB_DEPENDS=gmp.10:${PORTSDIR}/math/gmp \
mpfr.4:${PORTSDIR}/math/mpfr \
mpc.2:${PORTSDIR}/math/mpc
RUN_DEPENDS+= ${LOCALBASE}/bin/as:${PORTSDIR}/devel/binutils
Let's presume that a user defines WITH_GCC=4.6+ and then does make install
Re: WITH_GCC
on 06/05/2012 12:27 Andriy Gapon said the following:
My makefile-fu and ports-infrastructure-fu are really weak (maybe non-existent
even), but here is my attempt: [see the attachment].
The idea behind the patch:
- if WITH_GCC is not defined, then everything should be as before
- if WITH_GCC is defined, but USE_GCC is not defined, then USE_GCC gets set
from
WITH_GCC
- if both are defined
o if USE_GCC is a concrete version, then it wins
o else (if USE_GCC has the X+) form, then the minimum requested version
becomes MAX(X, Y), where Y is from WITH_GCC [*]
[*] Note that whether WITH_GCC has Y or Y+ form doesn't matter in this
case.
In all cases WITH_GCC can be used only to increase minimum required GCC
version,
unless a port wants a concrete fixed version.
Here's an updated version of the patch.
It should allow for initial bootstrapping of GCC itself.
BTW, what would be the more appropriate name for such a knob - WITH_GCC or
WANT_GCC?
--- /usr/ports/Mk/bsd.gcc.mk.orig 2012-05-06 11:12:55.628670003 +0300
+++ /usr/ports/Mk/bsd.gcc.mk2012-05-09 14:21:40.318673080 +0300
@@ -98,6 +98,30 @@ CONFIGURE_ENV+= F77=${F77} FC=${FC}
MAKE_ENV+= F77=${F77} FC=${FC} FFLAGS=${FFLAGS}
.endif
+.if defined(WITH_GCC) ${PORTNAME} != gcc
+
+# See if we can use a later version or exclusively the one specified.
+_WITH_GCC:=${WITH_GCC:S/+//}
+
+# Check if WITH_GCC points to a valid version.
+.for v in ${GCCVERSIONS}
+. for j in ${GCCVERSION_${v}}
+. if ${_WITH_GCC}==${j}
+_WITH_GCCVERSION_OKAY= true;
+. endif
+. endfor
+.endfor
+
+.if !defined(_WITH_GCCVERSION_OKAY)
+IGNORE=Unknown version of GCC specified (WITH_GCC=${WITH_GCC})
+.endif
+
+.if !defined(USE_GCC)
+USE_GCC:= ${WITH_GCC}
+.undef _WITH_GCC
+.endif
+
+.endif # WITH_GCC
.if defined(USE_GCC)
@@ -143,6 +167,11 @@ IGNORE=Couldn't find your current GCCV
# get the first available version.
#
.if defined(_GCC_ORLATER)
+. if defined(_WITH_GCC)
+. if ${_USE_GCC} ${_WITH_GCC}
+_USE_GCC:= ${_WITH_GCC}
+. endif
+. endif
. for v in ${GCCVERSIONS}
. if ${_USE_GCC} == ${_GCCVERSION_${v}_V}
_GCC_MIN1:=true
--
Andriy Gapon
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: WITH_GCC
On Thu, May 10, 2012 at 2:28 AM, Andriy Gapon a...@freebsd.org wrote: on 06/05/2012 12:27 Andriy Gapon said the following: My makefile-fu and ports-infrastructure-fu are really weak (maybe non-existent even), but here is my attempt: [see the attachment]. The idea behind the patch: - if WITH_GCC is not defined, then everything should be as before - if WITH_GCC is defined, but USE_GCC is not defined, then USE_GCC gets set from WITH_GCC - if both are defined o if USE_GCC is a concrete version, then it wins o else (if USE_GCC has the X+) form, then the minimum requested version becomes MAX(X, Y), where Y is from WITH_GCC [*] [*] Note that whether WITH_GCC has Y or Y+ form doesn't matter in this case. In all cases WITH_GCC can be used only to increase minimum required GCC version, unless a port wants a concrete fixed version. Here's an updated version of the patch. It should allow for initial bootstrapping of GCC itself. BTW, what would be the more appropriate name for such a knob - WITH_GCC or WANT_GCC? For Mk/bsd.database.mk - the meaning of USE_, WITH_ and WANT_ variables are: USE_* - Maintainer - Add dependency. If no version is given (by the maintainer via the port or by the user via defined variable), try to find the currently installed version. Fall back to default if necessary. WITH_*_VER - User defined variable to set version WANT_*_VER - Maintainer can set an arbitrary version to always build this port with (overrides WITH_*_VER). So the appropriate name for this user defined variable should be WITH_GCC since it sets both a dependancy and version for GCC as requested by the user. Scot ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: WITH_GCC
on 10/05/2012 19:48 Scot Hetzel said the following: For Mk/bsd.database.mk - the meaning of USE_, WITH_ and WANT_ variables are: USE_* - Maintainer - Add dependency. If no version is given (by the maintainer via the port or by the user via defined variable), try to find the currently installed version. Fall back to default if necessary. WITH_*_VER - User defined variable to set version WANT_*_VER - Maintainer can set an arbitrary version to always build this port with (overrides WITH_*_VER). So the appropriate name for this user defined variable should be WITH_GCC since it sets both a dependancy and version for GCC as requested by the user. Thank you very much! P.S. Perhaps this information should also be somewhere in the Porter's Handbook. -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: WITH_GCC
on 10/05/2012 10:28 Andriy Gapon said the following:
Here's an updated version of the patch.
It should allow for initial bootstrapping of GCC itself.
Next version of the patch...
Hopefully it should handle the bootstrapping better by accounting for lang/gcc*
ports dependencies and avoiding creating any circular dependencies.
For simplicity the GCC ports and their dependencies are forced to be built with
the base GCC, although this does not have to be required.
--- /usr/ports/Mk/bsd.gcc.mk.orig 2012-05-06 11:12:55.628670003 +0300
+++ /usr/ports/Mk/bsd.gcc.mk2012-05-10 18:49:27.218670582 +0300
@@ -98,6 +98,30 @@ CONFIGURE_ENV+= F77=${F77} FC=${FC}
MAKE_ENV+= F77=${F77} FC=${FC} FFLAGS=${FFLAGS}
.endif
+.if defined(WITH_GCC) ${PORTNAME} != gcc
+
+# See if we can use a later version or exclusively the one specified.
+_WITH_GCC:=${WITH_GCC:S/+//}
+
+# Check if WITH_GCC points to a valid version.
+.for v in ${GCCVERSIONS}
+. for j in ${GCCVERSION_${v}}
+. if ${_WITH_GCC}==${j}
+_WITH_GCCVERSION_OKAY= true;
+. endif
+. endfor
+.endfor
+
+.if !defined(_WITH_GCCVERSION_OKAY)
+IGNORE=Unknown version of GCC specified (WITH_GCC=${WITH_GCC})
+.endif
+
+.if !defined(USE_GCC)
+USE_GCC:= ${WITH_GCC}
+.undef _WITH_GCC
+.endif
+
+.endif # WITH_GCC
.if defined(USE_GCC)
@@ -143,6 +167,11 @@ IGNORE=Couldn't find your current GCCV
# get the first available version.
#
.if defined(_GCC_ORLATER)
+. if defined(_WITH_GCC)
+. if ${_USE_GCC} ${_WITH_GCC}
+_USE_GCC:= ${_WITH_GCC}
+. endif
+. endif
. for v in ${GCCVERSIONS}
. if ${_USE_GCC} == ${_GCCVERSION_${v}_V}
_GCC_MIN1:=true
@@ -178,24 +207,39 @@ _USE_GCC:=${GCC_DEFAULT_VERSION}
. if ${_USE_GCC} == ${_GCCVERSION_${v}_V}
. if ${OSVERSION} ${_GCCVERSION_${v}_L} || ${OSVERSION}
${_GCCVERSION_${v}_R}
V:=${_GCCVERSION_${v}_V:S/.//}
-_GCC_BUILD_DEPENDS:= gcc${V}
_GCC_PORT_DEPENDS:=gcc${V}
+. if ${V} == ${GCC_DEFAULT_V}
+_GCC_BUILD_DEPENDS:= gcc
+. else
+_GCC_BUILD_DEPENDS:= gcc${V}
+. endif
+_GCC_OWN_DEPENDS!= (cd ${PORTSDIR}/lang/${_GCC_BUILD_DEPENDS} ${MAKE} -V
_UNIFIED_DEPENDS)
+. for _CURDIR in ${.CURDIR} # only loop variable are expanded in variable
modifiers
+. if ${_GCC_OWN_DEPENDS:M*\:${_CURDIR}} !=
+.undef _GCC_BUILD_DEPENDS
+.undef _GCC_PORT_DEPENDS
+. else
CC:= gcc${V}
CXX:= g++${V}
CPP:= cpp${V}
-. if ${_USE_GCC} != 3.4
+.if ${_USE_GCC} != 3.4
CFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
+CFLAGS+= ${CFLAGS.${CC}}
+CXXFLAGS+= ${CXXFLAGS.${CC}}
LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
-.if defined (USE_FORTRAN)
-.if ${USE_FORTRAN} == yes
+. if defined (USE_FORTRAN)
+. if ${USE_FORTRAN} == yes
FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
-.endif
+. endif
+. endif
.endif
. endif
+. endfor
. endif
. endif
.endfor
.undef V
+.undef _GCC_OWN_DEPENDS
.if defined(_GCC_BUILD_DEPENDS)
BUILD_DEPENDS+=
${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_BUILD_DEPENDS}
--
Andriy Gapon
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
