Re: ports include /etc/src.conf? i.e. graphics/libfpx
On 2013/02/15 05:57, O. Hartmann wrote: Am 02/14/13 14:19, schrieb Yamaya Takashi: On 2013/02/13 22:33, Tom Evans wrote: On Wed, Feb 13, 2013 at 12:30 PM, Yamaya Takashi yama...@kbh.biglobe.ne.jp wrote: On 2013/02/13 19:08, O. Hartmann wrote: Setting only base system source compiler optins in /etc/src.conf, for instance # CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++11 which do NOT appear in /etc/make.conf, make building port grahpics/libfpx complaining about unrecognized compiler options. As far a sI know, /etc/src.conf is ONLY for building the source tree of the operating system and make.conf is supposed to contain all stuff necessary for compiling both world and ports, but /etc/src.conf is world only. Am I wrong? Oliver Yes. Because files/Makefile.bsd includes bsd.lib.mk, /etc/src.conf is included. src.conf(5) says: The only purpose of src.conf is to control the compilation of the FreeBSD source code, which is usually located in /usr/src. Cheers Tom src.conf(5) says: The values of variables are ignored regardless of their setting; even if they would be set to ``FALSE'' or ``NO''. Just the existence of an option will cause it to be honoured by make(1). The following list provides a name and short description for variables that can be used for source builds. Does it mean ONLY WITH_* and WITHOUT_* variables are allowed in /etc/src.conf? Shortly, there was a discussion about a fully installed LLVM/CLANG and the portion of LLVM/CLANG, that is only needed to compile the system's source. In this case, a strict separartion was intended. Not about llvm/clang. Including /etc/src.conf has problem of conflicting world knob and port knob. Skipping to include /etc/src.conf by bsd.own.mk is needed. It's difficult for base system. Then bsd.port.mk define _WITHOUT_SRCCONF and skip including /etc/src.conf. But some ports include bsd.*.mk (exclude bsd.port*.mk) has bug, because they don't define _WITHOUT_SRCCONF. If the manpage of /etc/src.conf says that only bool knobs are allowed like WITH_XXX or WITHOUT_XXX, then: where to put the options? NOT bool, the variable is defined or not. The options are written in /etc/make.conf ___ 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: ports include /etc/src.conf? i.e. graphics/libfpx
On 2013/02/16 15:46, Mikhail T. wrote:
15.02.2013 23:21, Ian Lepore ???(??):
Since /home/ian/foo/BSDmakefile is not building something that is part
of the freebsd world, or the freebsd kernel, then according to that
paragraph, a build using that makefile should not be affected
by /etc/src.conf.
Maybe it should not be affected. But it is. And the only way to avoid it
is by using an undocumented knob. If the documentation properly
documents the feature, then the implementation of it is faulty.
As suggested earlier, perhaps, the file should only be included, if
something special is put into environment (by /usr/src/Makefile).
Instead it bsd.own.mk currently sucks-in /etc/src.conf by default -- and
one has to set an undocumented flag to avoid that. Something like this
(untested):
Index: Makefile
===
--- Makefile(revision 246385)
+++ Makefile(working copy)
@@ -293,7 +293,7 @@
# the system bsdmake-like utility to be overridden.
#
MMAKEENV= MAKEOBJDIRPREFIX=${MAKEPATH} \
- DESTDIR= \
+ DESTDIR= _WITH_SRCCONF= \
INSTALL=sh ${.CURDIR}/tools/install.sh
MMAKE= ${MMAKEENV} ${MAKE} \
-D_UPGRADING \
Index: share/mk/bsd.own.mk
===
--- share/mk/bsd.own.mk (revision 246385)
+++ share/mk/bsd.own.mk (working copy)
@@ -115,7 +115,7 @@
.if !target(__bsd.own.mk__)
__bsd.own.mk__:
-.if !defined(_WITHOUT_SRCCONF)
+.if defined(_WITH_SRCCONF)
SRCCONF?= /etc/src.conf
.if exists(${SRCCONF})
.include ${SRCCONF}
Yours,
-mi
___
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
/etc/src.conf is never included.
MMAKE* seems for usr.bin/make.
bsd.own.mk has 2 !defined(_WITHOUT_SRCCONF).
first is changed, but second is not. Why?
_WITH_SRCCONF is defined only root Makefile.
Is this correct?
I think subdir's Makefile need to include /etc/src.conf.
___
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: ports include /etc/src.conf? i.e. graphics/libfpx
14.02.2013 09:34, Peter Pentchev ???(??): However, there is then the argument of well, if you want to use the bsd.*.mk infrastructure, then why don't you just copy it into your project and include it from there - just like many, many projects do with, say, the sys/queue.h header, or parts of libc, or whatever? And it is, indeed, a very good argument Either I completely misunderstand the argument, or I disagree -- strongly -- with it. Including bits created and maintained by others into your own project is very rarely justified (although done quite often). I don't see, why adding (some version of) bsd.lib.mk and friends into every project, that wishes to build a shared library on FreeBSD, is any more justified, than bundling libjpeg with every graphics application. John-Mark also just posted a strong argument for using the existing bsd.*.mk family of makefiles... since this is how a software distribution's parts are supposed to be used - you copy them into your project and use them even when they are not available on the host system. So one might argue that the port is, indeed, buggy, that the src.conf documentation is, indeed, correct, and that the proper way for people to use the bsd.*.mk The documentation is, demonstrably, incorrect -- it was incorrect, when it was written 7 years ago, and remains so. Because a user of bsd.*.mk /will be/ affected by src.conf -- unless he takes special steps to prevent it. This fact can not be fixed by a user, the only way to avoid the effect, is to modify their own makefile(s). The implementation of the change may be blamed for this -- if, indeed, there was a need for src-only configuration knobs, src.conf should be included, when a special flag is present in the environment (put there by src/Makefile), not the other way around. some weird src.conf settings might confuse the build of some of my software on FreeBSD. And some of those settings are required for healthy building of some of the ports... For example, libreoffice knows out of the box, that FreeBSD has Kerberos libraries. So, if your world was built WITHOUT_KERBEROS and WITHOUT_GSSAPI, libreoffice fails to configure. A simple patch like: +.if defined(WITHOUT_KERBEROS) +CONFIGURE_ARGS+= --without-krb5 +.endif +.if defined(WITHOUT_GSSAPI) +CONFIGURE_ARGS+= --without-gssapi +.endif could help, but WITHOUT_KERBEROS and WITHOUT_GSSAPI are set in src.conf and not, normally, available to the ports... So, in my opinion, the manual (src.conf(5)) should be updated to reflect reality. Or, if the separation is really deemed desirable (something I, for one, continue to question), the implementation (in /usr/src/Makefile and bsd.own.mk) needs to be altered to only consider src.conf, when world/kernel are being built/installed. -mi ___ 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: ports include /etc/src.conf? i.e. graphics/libfpx
Peter Pentchev wrote this message on Thu, Feb 14, 2013 at 16:34 +0200: There are some people - and some of them are well-respected long-term Free-and-other-BSD developers - who are of the opinion that the /usr/share/mk/bsd.*.mk infrastructure is meant for the base system build only. I do indeed understand this point of view - and from this point of view, the port's Makefile.bsd is buggy because it allegedly abuses internal parts of the base system. They are documented for use by everyone in the system... hier(7): mk/templates for make; see make(1) make(1): -m directory Specify a directory in which to search for the system makefile and makefiles included via the ... style. Multiple -m options can be specified to form a search path. This path will override the default system include path, /usr/share/mk. The system include path will always be appended to the search path used for ...-style inclusions and makefile searches (see the -I option). and: /usr/share/mk default system makefile directory make should not include the directory by default if it isn't designed for use by people that use make... If it /usr/share/mk is only for the default system, we need to fix make to not include it by default, and make /usr/src/Makefile and friends do the properly thing... Until then, /usr/share/mk is for use by projects outside /usr/src... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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: ports include /etc/src.conf? i.e. graphics/libfpx
On Fri, 2013-02-15 at 17:32 -0500, Mikhail T. wrote: 14.02.2013 09:34, Peter Pentchev ???(??): However, there is then the argument of well, if you want to use the bsd.*.mk infrastructure, then why don't you just copy it into your project and include it from there - just like many, many projects do with, say, the sys/queue.h header, or parts of libc, or whatever? And it is, indeed, a very good argument Either I completely misunderstand the argument, or I disagree -- strongly -- with it. Including bits created and maintained by others into your own project is very rarely justified (although done quite often). I don't see, why adding (some version of) bsd.lib.mk and friends into every project, that wishes to build a shared library on FreeBSD, is any more justified, than bundling libjpeg with every graphics application. John-Mark also just posted a strong argument for using the existing bsd.*.mk family of makefiles... since this is how a software distribution's parts are supposed to be used - you copy them into your project and use them even when they are not available on the host system. So one might argue that the port is, indeed, buggy, that the src.conf documentation is, indeed, correct, and that the proper way for people to use the bsd.*.mk The documentation is, demonstrably, incorrect -- it was incorrect, when it was written 7 years ago, and remains so. Because a user of bsd.*.mk /will be/ affected by src.conf -- unless he takes special steps to prevent it. This fact can not be fixed by a user, the only way to avoid the effect, is to modify their own makefile(s). The implementation of the change may be blamed for this -- if, indeed, there was a need for src-only configuration knobs, src.conf should be included, when a special flag is present in the environment (put there by src/Makefile), not the other way around. some weird src.conf settings might confuse the build of some of my software on FreeBSD. And some of those settings are required for healthy building of some of the ports... For example, libreoffice knows out of the box, that FreeBSD has Kerberos libraries. So, if your world was built WITHOUT_KERBEROS and WITHOUT_GSSAPI, libreoffice fails to configure. A simple patch like: +.if defined(WITHOUT_KERBEROS) +CONFIGURE_ARGS+= --without-krb5 +.endif +.if defined(WITHOUT_GSSAPI) +CONFIGURE_ARGS+= --without-gssapi +.endif could help, but WITHOUT_KERBEROS and WITHOUT_GSSAPI are set in src.conf and not, normally, available to the ports... So, in my opinion, the manual (src.conf(5)) should be updated to reflect reality. Or, if the separation is really deemed desirable (something I, for one, continue to question), the implementation (in /usr/src/Makefile and bsd.own.mk) needs to be altered to only consider src.conf, when world/kernel are being built/installed. The src.conf manpage is not in error. The intent is that src.conf applies only to the building of the freebsd world and kernel, that is, the source that's usually located under /usr/src. If settings from src.conf are leaking into other builds, the error is in the makefiles, not in the manpage. Unambiguous evidence of this can be found in the email announcing the new src.conf file and why it was created: http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061725.html I'm not an expert with the build system, and that goes double for ports, so I can't say exact how or why it's broken, or when the breakage happened (or even if it's been broken from the very beginning), but I think that announcement email makes it clear the bug isn't the documentation. -- Ian ___ 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: ports include /etc/src.conf? i.e. graphics/libfpx
15.02.2013 19:12, Ian Lepore ???(??): The src.conf manpage is not in error. The intent is that src.conf applies only to the building of the freebsd world and kernel, that is, the source that's usually located under /usr/src. If settings from src.conf are leaking into other builds, the error is in the makefiles, not in the manpage. Unambiguous evidence of this can be found in the email announcing the new src.conf file and why it was created: http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061725.html I'm not an expert with the build system, and that goes double for ports, so I can't say exact how or why it's broken, or when the breakage happened (or even if it's been broken from the very beginning), but I think that announcement email makes it clear the bug isn't the documentation. Thank you, sir, for posting the link. Once I read it, however, I am puzzled. Because, contrary to what you are saying,it makes no statement about whether or not knobs in src.conf are (or are not) supposed to affect makefiles outside of /usr/src. The only paragraph mentioning the new file says: - Options can be passed on the make(1) command line or in the new /etc/src.conf (overrideable). The reason for the new src.conf is so we keep make(1) environment clean from these variables outside world/kernel builds (make.conf pollutes the environment as it's included by sys.mk). I fail to see, where in the above it says, that a private project's /home/ian/foo/BSDmakefile is not supposed to be affected by the system's /etc/src.conf. Do you? There may be other reasons for src.conf(5) to claim, what it claims about the file's only purpose, but the e-mail you referred to is not one of them. -mi ___ 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: ports include /etc/src.conf? i.e. graphics/libfpx
On Fri, 2013-02-15 at 23:09 -0500, Mikhail T. wrote: 15.02.2013 19:12, Ian Lepore ???(??): The src.conf manpage is not in error. The intent is that src.conf applies only to the building of the freebsd world and kernel, that is, the source that's usually located under /usr/src. If settings from src.conf are leaking into other builds, the error is in the makefiles, not in the manpage. Unambiguous evidence of this can be found in the email announcing the new src.conf file and why it was created: http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061725.html I'm not an expert with the build system, and that goes double for ports, so I can't say exact how or why it's broken, or when the breakage happened (or even if it's been broken from the very beginning), but I think that announcement email makes it clear the bug isn't the documentation. Thank you, sir, for posting the link. Once I read it, however, I am puzzled. Because, contrary to what you are saying,it makes no statement about whether or not knobs in src.conf are (or are not) supposed to affect makefiles outside of /usr/src. The only paragraph mentioning the new file says: - Options can be passed on the make(1) command line or in the new /etc/src.conf (overrideable). The reason for the new src.conf is so we keep make(1) environment clean from these variables outside world/kernel builds (make.conf pollutes the environment as it's included by sys.mk). I fail to see, where in the above it says, that a private project's /home/ian/foo/BSDmakefile is not supposed to be affected by the system's /etc/src.conf. Do you? There may be other reasons for src.conf(5) to claim, what it claims about the file's only purpose, but the e-mail you referred to is not one of them. -mi Since /home/ian/foo/BSDmakefile is not building something that is part of the freebsd world, or the freebsd kernel, then according to that paragraph, a build using that makefile should not be affected by /etc/src.conf. I don't see any way to interpret the paragraph you cited other than meaning that src.conf is intended to affect only world/kernel builds. I mean, it says that. It says *exactly* that. It even mentions the existance of the file that should be used for settings that affect things outside of world and kernel builds, to help emphasize the difference with how src.conf is intended to be used. -- Ian ___ 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: Re: ports include /etc/src.conf? i.e. graphics/libfpx
13.02.2013 11:22, O. Hartmann написав(ла): If this is taken literally then could it be said that ports that use bsd.lib.mk are broken because they are using makefile includes from the source tree? -Kimmo For one, the particular port (its Makefile.bsd) was created in 2001, five years before src.conf appeared. The intent of creating a separate src.conf, I believe, was to shield a world-build from crazy options someone could've put into their make.conf for the benefit of building a port or two... But I may be mistaken. I would consider them broken! On the contrary. I wish, more ports were using the system's bsd.*.mk collection -- instead of the godawful autoconf, for example. What does the port's Makefile.bsd say? It says: These are the sources, this is the name of the library I want. Please, create it. That's all... It is how things are supposed to be, in my opinion. If the bsd.*.mk collection was not meant to be used outside of /usr/src, then it wouldn't be installed (under /usr/share/mk) for the decades, that BSD exists. Maybe, the bsd.*.mk collection should be smarter -- and not include src.conf -- when .CURDIR is outside of /usr/src. I'm not sure... How could I track down problems if they are results of intermixed config files when the manpage explicitely tells me, that the /etc/src.conf is only for the build of the operating system? If the manual says that, it is incorrect -- if only because it does not reflect (as you've experienced) the practice, that existed long before the manual was written. As for your tracking down problems, I'd say, it should be very easy for you to recognize the flags you've added by hand -- even if you've added them to where you believed, they would not affect a port. -mi ___ 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: Re: ports include /etc/src.conf? i.e. graphics/libfpx
On Thu, Feb 14, 2013 at 12:27 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: 13.02.2013 11:22, O. Hartmann написав(ла): If this is taken literally then could it be said that ports that use bsd.lib.mk are broken because they are using makefile includes from the source tree? -Kimmo For one, the particular port (its Makefile.bsd) was created in 2001, five years before src.conf appeared. The intent of creating a separate src.conf, I believe, was to shield a world-build from crazy options someone could've put into their make.conf for the benefit of building a port or two... But I may be mistaken. I think src.conf is meant only to be included when building src. For example, bsd.port.mk sets _WITHOUT_SRCCONF before including bsd.own.mk (which is the makefile that includes src.conf). It's done this since src.conf was added in 2006, so evidently ports are, by design, not supposed to include src.conf. I would consider them broken! On the contrary. I wish, more ports were using the system's bsd.*.mk collection -- instead of the godawful autoconf, for example. Er? What port uses autoconf for driving the building the port? A lot of ports have build systems that use autoconf, but determining how to build is always driven by *.mk. I don't think part of porting to FreeBSD should be rewriting how the package builds itself. The intent in bsd.port.mk is clearly to not include src.conf in port builds. What does the port's Makefile.bsd say? It says: These are the sources, this is the name of the library I want. Please, create it. That's all... It is how things are supposed to be, in my opinion. If the bsd.*.mk collection was not meant to be used outside of /usr/src, then it wouldn't be installed (under /usr/share/mk) for the decades, that BSD exists. Maybe, the bsd.*.mk collection should be smarter -- and not include src.conf -- when .CURDIR is outside of /usr/src. I'm not sure... This is the intent of bsd.port.mk, which is not applied when building this port. How could I track down problems if they are results of intermixed config files when the manpage explicitely tells me, that the /etc/src.conf is only for the build of the operating system? If the manual says that, it is incorrect -- if only because it does not reflect (as you've experienced) the practice, that existed long before the manual was written. As for your tracking down problems, I'd say, it should be very easy for you to recognize the flags you've added by hand -- even if you've added them to where you believed, they would not affect a port. Either the documentation is wrong, and should be changed, or this singular port is not behaving as it should. Cheers Tom ___ 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: ports include /etc/src.conf? i.e. graphics/libfpx
14.02.2013 08:02, Tom Evans написав(ла): I think src.conf is meant only to be included when building src. For example, bsd.port.mk sets _WITHOUT_SRCCONF before including bsd.own.mk (which is the makefile that includes src.conf). It's done this since src.conf was added in 2006, so evidently ports are, by design, not supposed to include src.conf. Awesome. All that's missing then, is for _WITHOUT_SRCCONF to be automatically added to MAKE_ENV... I would consider them broken! On the contrary. I wish, more ports were using the system's bsd.*.mk collection -- instead of the godawful autoconf, for example. Er? What port uses autoconf for driving the building the port? A lot of ports have build systems that use autoconf, but determining how to build is always driven by *.mk. I don't think part of porting to FreeBSD should be rewriting how the package builds itself. Hundreds of ports rely on auto-something bundled with the vendor's sources, that's what I meant. As for how to build a particular package, that's up to the port-maintainer. Either the documentation is wrong, and should be changed, or this singular port is not behaving as it should. I may sound defensive here, but I'll still repeat, that this singular port (and I do, in fact, have other ones like it) started using bsd.lib.mk 5 years before src.conf (and its man-page) was added to the tree. -mi ___ 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: ports include /etc/src.conf? i.e. graphics/libfpx
On 2013/02/13 22:33, Tom Evans wrote: On Wed, Feb 13, 2013 at 12:30 PM, Yamaya Takashi yama...@kbh.biglobe.ne.jp wrote: On 2013/02/13 19:08, O. Hartmann wrote: Setting only base system source compiler optins in /etc/src.conf, for instance # CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++11 which do NOT appear in /etc/make.conf, make building port grahpics/libfpx complaining about unrecognized compiler options. As far a sI know, /etc/src.conf is ONLY for building the source tree of the operating system and make.conf is supposed to contain all stuff necessary for compiling both world and ports, but /etc/src.conf is world only. Am I wrong? Oliver Yes. Because files/Makefile.bsd includes bsd.lib.mk, /etc/src.conf is included. src.conf(5) says: The only purpose of src.conf is to control the compilation of the FreeBSD source code, which is usually located in /usr/src. Cheers Tom src.conf(5) says: The values of variables are ignored regardless of their setting; even if they would be set to ``FALSE'' or ``NO''. Just the existence of an option will cause it to be honoured by make(1). The following list provides a name and short description for variables that can be used for source builds. Does it mean ONLY WITH_* and WITHOUT_* variables are allowed in /etc/src.conf? ___ 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: ports include /etc/src.conf? i.e. graphics/libfpx
On Thu, Feb 14, 2013 at 1:12 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: I may sound defensive here, but I'll still repeat, that this singular port (and I do, in fact, have other ones like it) started using bsd.lib.mk 5 years before src.conf (and its man-page) was added to the tree. -mi This is true. But what is the bug, that the port's Makefile.bsd was not updated on the introduction of src.conf to DTRT (and no-one noticed for 7 years), or that the purpose of src.conf has been mistakenly documented for 7 years? Cheers Tom ___ 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: ports include /etc/src.conf? i.e. graphics/libfpx
14.02.2013 08:55, Tom Evans написав(ла):
On Thu, Feb 14, 2013 at 1:12 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
I may sound defensive here, but I'll still repeat, that this singular
port
(and I do, in fact, have other ones like it) started using bsd.lib.mk 5
years before src.conf (and its man-page) was added to the tree.
This is true. But what is the bug, that the port's Makefile.bsd was
not updated on the introduction of src.conf to DTRT (and no-one
noticed for 7 years), or that the purpose of src.conf has been
mistakenly documented for 7 years?
I think, the bug is either in documentation or implementation of
src.conf (if it had to be implemented at all, that is) -- there was
never (and still is not) any suggestion, that bsd.{prog,lib}.mk are not
supposed to be used by other people's software.
Maybe, if the file is really meant to be used by *world and *kernel
targets, the knob should've been _WITH_SRCONF -- and added to the
environment by src/Makefile? Because, forget ports for a second, what if
my own little project uses bsd.prog.mk -- because Makefiles using it
tend to fit in a window without scrolling?
I'd say, the documentation should be updated to state, that src.conf
will affect anything, that uses bsd.*.mk family of makefiles, unless
_WITHOUT_SRCCONF is set. The entire /usr/src as well as some of the
ports may then be listed as examples of the areas affected. This will
reflect reality and help avoid frustration that O. Hartmann went through.
-mi
___
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: ports include /etc/src.conf? i.e. graphics/libfpx
On Thu, Feb 14, 2013 at 01:55:58PM +, Tom Evans wrote: On Thu, Feb 14, 2013 at 1:12 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: I may sound defensive here, but I'll still repeat, that this singular port (and I do, in fact, have other ones like it) started using bsd.lib.mk 5 years before src.conf (and its man-page) was added to the tree. -mi This is true. But what is the bug, that the port's Makefile.bsd was not updated on the introduction of src.conf to DTRT (and no-one noticed for 7 years), or that the purpose of src.conf has been mistakenly documented for 7 years? To be brutally honest, and at some cost to myself, I would have to say both :( There are some people - and some of them are well-respected long-term Free-and-other-BSD developers - who are of the opinion that the /usr/share/mk/bsd.*.mk infrastructure is meant for the base system build only. I do indeed understand this point of view - and from this point of view, the port's Makefile.bsd is buggy because it allegedly abuses internal parts of the base system. At the same time (see the last paragraph) I do quite understand the other point of view - that FreeBSD is not merely an operating system or a combination of an operating system and third-party software adapted to work on it consistently, but that it is a software distribution (what, after all, does BSD mean? :). Hence, its source code is meant to be adopted, adapted and used in everyone's software projects when everyone feels like it (under the conditions of the respective licenses, of course). If this is taken to mean that if we have bsd.*.mk, we are free to use it, then it will turn out that bsd.*.mk is not really an internal part of the base system, and that the documentation for src.conf maybe ought to mention that the settings there may affect the build of third-party programs that use the bsd.*.mk infrastructure (and of course there would be no way to list all such programs). However... However, there is then the argument of well, if you want to use the bsd.*.mk infrastructure, then why don't you just copy it into your project and include it from there - just like many, many projects do with, say, the sys/queue.h header, or parts of libc, or whatever? And it is, indeed, a very good argument, since this is how a software distribution's parts are supposed to be used - you copy them into your project and use them even when they are not available on the host system. So one might argue that the port is, indeed, buggy, that the src.conf documentation is, indeed, correct, and that the proper way for people to use the bsd.*.mk infrastructure in their own projects is to take a snapshot, remove the include /etc/rc.conf part, change the include statements to be relative to the current directory or something, and then include the bsd.*.mk files from their own project's source directory. I'm not sure if there are any projects that actually do that, but IMHO this is the correct way to do it :) Now, in this particular case, we have a slightly different situation when the code that uses the bsd.*.mk infrastructure is not part of the upstream software source code, but is part of the FreeBSD port - that is, it is supposed to work mostly on FreeBSD, and the port is supposed to keep up with the times and work around any incompatible bsd.*.mk changes. So... with all due respect to Mikhail, I do believe that in this case the port's Makefile.bsd ought to add the without src.conf definition before including the bsd.*.mk parts. The at some cost to myself part at the start of this message is because some of my released software uses the bsd.prog.mk/bsd.lib.mk infrastructure, with the unspoken assumption that I'll update it when the bsd.*.mk infrastructure changes in incompatible ways (this has not really happened for the past twelve years, mostly because my Makefiles do not try to use NO_MAN or similar options - they define everything they need, and it is not a whole lot :) So... yeah, I've been lazy, and yeah, some weird src.conf settings might confuse the build of some of my software on FreeBSD. And, of course, my software might very well not build at all on other BSD-like host platforms. But... yeah, well, I've been lazy ;) ...thanks for reading so far, I guess :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 When you are not looking at it, this sentence is in Spanish. signature.asc Description: Digital signature
Re: ports include /etc/src.conf? i.e. graphics/libfpx
Am 02/14/13 14:19, schrieb Yamaya Takashi: On 2013/02/13 22:33, Tom Evans wrote: On Wed, Feb 13, 2013 at 12:30 PM, Yamaya Takashi yama...@kbh.biglobe.ne.jp wrote: On 2013/02/13 19:08, O. Hartmann wrote: Setting only base system source compiler optins in /etc/src.conf, for instance # CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++11 which do NOT appear in /etc/make.conf, make building port grahpics/libfpx complaining about unrecognized compiler options. As far a sI know, /etc/src.conf is ONLY for building the source tree of the operating system and make.conf is supposed to contain all stuff necessary for compiling both world and ports, but /etc/src.conf is world only. Am I wrong? Oliver Yes. Because files/Makefile.bsd includes bsd.lib.mk, /etc/src.conf is included. src.conf(5) says: The only purpose of src.conf is to control the compilation of the FreeBSD source code, which is usually located in /usr/src. Cheers Tom src.conf(5) says: The values of variables are ignored regardless of their setting; even if they would be set to ``FALSE'' or ``NO''. Just the existence of an option will cause it to be honoured by make(1). The following list provides a name and short description for variables that can be used for source builds. Does it mean ONLY WITH_* and WITHOUT_* variables are allowed in /etc/src.conf? Shortly, there was a discussion about a fully installed LLVM/CLANG and the portion of LLVM/CLANG, that is only needed to compile the system's source. In this case, a strict separartion was intended. This implies w have setting only applicable for the core system and we deal with settings for various ports. I though, until now, FreeBSD, as other *BSDs, follow a strict logical policy and this implies, in my opinion, that there is in strictu sensu a separation between the sources of the core system and those for the ports. If the manpage of /etc/src.conf says that only bool knobs are allowed like WITH_XXX or WITHOUT_XXX, then: where to put the options? I feel confused by having /etc/src.conf also involved in port's compilations and in my opinion, this is a bug! It torpedos the logic described in the manpage with sounds reasonable to me (the manpage of src.conf). If the build system really needs to intertwine both make.conf and src.conf for ports, then something is illconditioned. signature.asc Description: OpenPGP digital signature
Re: ports include /etc/src.conf? i.e. graphics/libfpx
On Wed, Feb 13, 2013 at 12:30 PM, Yamaya Takashi yama...@kbh.biglobe.ne.jp wrote: On 2013/02/13 19:08, O. Hartmann wrote: Setting only base system source compiler optins in /etc/src.conf, for instance # CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++11 which do NOT appear in /etc/make.conf, make building port grahpics/libfpx complaining about unrecognized compiler options. As far a sI know, /etc/src.conf is ONLY for building the source tree of the operating system and make.conf is supposed to contain all stuff necessary for compiling both world and ports, but /etc/src.conf is world only. Am I wrong? Oliver Yes. Because files/Makefile.bsd includes bsd.lib.mk, /etc/src.conf is included. src.conf(5) says: The only purpose of src.conf is to control the compilation of the FreeBSD source code, which is usually located in /usr/src. Cheers Tom ___ 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: ports include /etc/src.conf? i.e. graphics/libfpx
On Wed, Feb 13, 2013 at 3:33 PM, Tom Evans tevans...@googlemail.com wrote: On Wed, Feb 13, 2013 at 12:30 PM, Yamaya Takashi yama...@kbh.biglobe.ne.jp wrote: On 2013/02/13 19:08, O. Hartmann wrote: Setting only base system source compiler optins in /etc/src.conf, for instance # CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++11 which do NOT appear in /etc/make.conf, make building port grahpics/libfpx complaining about unrecognized compiler options. As far a sI know, /etc/src.conf is ONLY for building the source tree of the operating system and make.conf is supposed to contain all stuff necessary for compiling both world and ports, but /etc/src.conf is world only. Am I wrong? Oliver Yes. Because files/Makefile.bsd includes bsd.lib.mk, /etc/src.conf is included. src.conf(5) says: The only purpose of src.conf is to control the compilation of the FreeBSD source code, which is usually located in /usr/src. Cheers Tom If this is taken literally then could it be said that ports that use bsd.lib.mk are broken because they are using makefile includes from the source tree? -Kimmo ___ 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: ports include /etc/src.conf? i.e. graphics/libfpx
Am 02/13/13 15:05, schrieb Kimmo Paasiala: On Wed, Feb 13, 2013 at 3:33 PM, Tom Evans tevans...@googlemail.com wrote: On Wed, Feb 13, 2013 at 12:30 PM, Yamaya Takashi yama...@kbh.biglobe.ne.jp wrote: On 2013/02/13 19:08, O. Hartmann wrote: Setting only base system source compiler optins in /etc/src.conf, for instance # CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++11 which do NOT appear in /etc/make.conf, make building port grahpics/libfpx complaining about unrecognized compiler options. As far a sI know, /etc/src.conf is ONLY for building the source tree of the operating system and make.conf is supposed to contain all stuff necessary for compiling both world and ports, but /etc/src.conf is world only. Am I wrong? Oliver Yes. Because files/Makefile.bsd includes bsd.lib.mk, /etc/src.conf is included. src.conf(5) says: The only purpose of src.conf is to control the compilation of the FreeBSD source code, which is usually located in /usr/src. Cheers Tom If this is taken literally then could it be said that ports that use bsd.lib.mk are broken because they are using makefile includes from the source tree? -Kimmo I would consider them broken! How could I track down problems if they are results of intermixed config files when the manpage explicitely tells me, that the /etc/src.conf is only for the build of the operating system? signature.asc Description: OpenPGP digital signature
