Simon Barner wrote:
Rene Rivera wrote:
But for these sorts of changes to work generically it would be better to condition specifically on FreeBSD, after all there are other BSDs out there. For example instead of the above:
case FreeBSD : { flags gcc LINKFLAGS <stlport-iostream>on : $(PTHREAD_LIBS) ; } case *BSD : { flags gcc LINKFLAGS <stlport-iostream>on : -pthread ; }
The problem is that the PTHREAD_{LIBS,CFLAGS} variables are available in the ports framework only (which sets them according to the underlying FreeBSD version).
Well it could be changed so that it handles both situations, building outside of the ports framework and within it. By checking if the PTHREADS_LIBS, or some other var that is specific to the ports build, and providing code for both possibilities.
If the boost distribution was changed to use those variables for FreeBSD, users no longer would be able to build Boost directly from the tarballs, which certainly is not desired.
OK, I misunderstood, I thought that these where general requirements for building on FreeBSD.
To sum this up: flags gcc LINKFLAGS ... : -pthread and flags gcc CFLAGS ... : is fine for recent versions of FreeBSD 5.
The exact requirements would be
.if ${OSVERSION} < 500016 PTHREAD_CFLAGS?= -D_THREAD_SAFE PTHREAD_LIBS?= -pthread .elif ${OSVERSION} < 502102 PTHREAD_CFLAGS?= -D_THREAD_SAFE PTHREAD_LIBS?= -lc_r .else PTHREAD_CFLAGS?= PTHREAD_LIBS?= -pthread .endif
but I doubt that this could be reflected directly in the jam file (or is there a way to query the exakt OS version?).
Never fear... If you can deduce what you need to do from the output of "uname -a" you can do it. That is because the different parts of "uname -a" are reflected in the $(JAMUNAME) variable. For example on my OpenBSD JAMUNAME is: "OpenBSD" "red5of5" "3.2" "RED5OF5#2" "i386" So to get the OS version you do: $(JAMUNAME[3])
IMO the best thing is to leave the jam files unchanged, and I will keep those tow patches in the ports collection in order to handle those special cases. This is not uncommon in the ports collection.
Possibly, and it is your choice ;-) But ultimately it would be best to make sure we support any platform build requirements. And the above looks like it's a platform requirement to me as it pertains to the libraries used for threading support. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq