Boost 1.55.0 (Was: Re: PowerPC Packages)

[Baptiste Daroussin]

On Thu, Jun 26, 2014 at 12:03:42PM -0700, Nathan Whitehorn wrote:
> 
> On 06/26/14 12:00, Baptiste Daroussin wrote:
> > On Thu, Jun 26, 2014 at 11:30:39AM -0700, Justin Hibbits wrote:
> >> On Thu, Jun 26, 2014 at 10:38 AM, Nathan Whitehorn
> >> <nwhitehorn at freebsd.org> wrote:
> >>> On 06/26/14 08:44, Baptiste Daroussin wrote:
> >>>> On Thu, Jun 26, 2014 at 08:35:14AM -0700, Nathan Whitehorn wrote:
> >>>>> On 06/26/14 03:02, Alexey Dokuchaev wrote:
> >>>>>> On Wed, Jun 25, 2014 at 07:23:05AM -0700, Justin Hibbits wrote:
> >>>>>>> As I mentioned earlier, you can set "FAVORITE_COMPILER=gcc" in
> >>>>>>> make.conf, and it'll build with gcc47.
> >>>>>> FAVORITE_COMPILER looks more like a hack to me.  Ideally boost's port
> >>>>>> Makefile should be fixed instead.
> >>>>>>
> >>>>>> I also would rather use system compiler (whether it's gcc4.2 or clang)
> >>>>>> instead of gcc47.
> >>>>>>
> >>>>>> ./danfe
> >>>>>>
> >>>>> Yes, it should be made to respect whatever cc is.
> >>>> As long as cc is supported upstream, boost being a nightmare to maintain I
> >>>> will
> >>>> reject all patches that are not accepted upstream first, otherwise bumping
> >>>> to
> >>>> 1.56 will be painful.
> >>>>
> >>>> That said I fully support the effort.
> >>>>
> >>>> regards,
> >>>> Bapt
> >>>
> >>> The following patch fixes the issue for me (as well as several other ports).
> >>> I'll let you decide whether this is how you want to handle the problem.
> >>> -Nathan
> >>>
> >>> Index: Mk/Uses/compiler.mk
> >>> ===================================================================
> >>> --- Mk/Uses/compiler.mk (revision 358026)
> >>> +++ Mk/Uses/compiler.mk (working copy)
> >>> @@ -75,7 +75,9 @@
> >>>   ALT_COMPILER_TYPE=     none
> >>>   _ALTCCVERSION=
> >>>   .if ${COMPILER_TYPE} == gcc && exists(/usr/bin/clang)
> >>> +.if ${ARCH} == amd64 || ${ARCH} == i386 # clang often non-default for a
> >>> reason
> >>>   _ALTCCVERSION!=        /usr/bin/clang --version
> >>> +.endif
> >>>   .elif ${COMPILER_TYPE} == clang && exists(/usr/bin/gcc)
> >>>   _ALTCCVERSION!=        /usr/bin/gcc --version
> >>>   .endif
> >>> @@ -138,7 +140,7 @@
> >>>
> >>>   .if ${_COMPILER_ARGS:Mc++11-lang}
> >>>   .if !${COMPILER_FEATURES:Mc++11}
> >>> -.if defined(FAVORITE_COMPILER) && ${FAVORITE_COMPILER} == gcc
> >>> +.if (defined(FAVORITE_COMPILER) && ${FAVORITE_COMPILER} == gcc) || (${ARCH}
> >>> != amd64 || ${ARCH} != i386) # clang not always supported on Tier-2
> >>>   USE_GCC=       yes
> >>>   CHOSEN_COMPILER_TYPE=  gcc
> >>>   .elif (${COMPILER_TYPE} == clang && ${COMPILER_VERSION} < 33) ||
> >>> ${COMPILER_TYPE} == gcc
> >>>
> >> bapt mentioned a while back about separating the concept of the 'base
> >> compiler' and 'ports compiler'.  Perhaps we need to explore this
> >> again.  It should be possible to mark ports as being dependencies for
> >> the ports compiler, and all other ports would get built by said
> >> compiler, while those are built by the base compiler.  This way we can
> >> take advantage of any enhancements we might get with a newer compiler
> >> (like better altivec support and autovectorization from newer gcc,
> >> better optimizations, etc).
> >>
> >> - Justin
> > nathan, I all for what you did, except that we should also add arm to the clang
> > list ;)
> 
> I think that should work automatically. Isn't clang cc on ARM? This only 
> has an affect if cc is gcc and clang is also installed. The assumption 
> is that clang is non-default for a reason in such cases (except for 
> stable/10 x86, which is special-cased).
> -Nathan

Ah true, please commmit that

regards,
Bapt
> 
> > Can you look at compiler.mk and apply the same concept?
> >
> > justin I m still looking in that direction, but that implies the full c++ stack
> > (which is a nightmare on all pre freebsd10) because anything asking for C++11
> > support will require a newer libc++ than the one shipped in base in case we use
> > gcc to build base. and mising libstdc++ all together can give you terrific
> > headache sometime ;)
> >
> > regards,
> > Bapt
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ppc/attachments/20140626/90da9e03/attachment.sig>