Re: pkgsrc frozen for 2017Q2

[Jason Bacon <bacon4000%gmail.com@localhost>]

On 06/29/17 09:23, Greg Troxel wrote:
> It's not really that googletest is broken.  It's that the combination of
>
>    C++ not being a single stable language
>    C++ not having a stable ABI
>    people using old compilers
>    how the mk/ framework is
>    people not setting a global GCC_REQD
>
> is broken.  So it's not clear that googletest should be "fixed".
I wasn't implying that the googletest package is the problem.  By 
"broken", I simply mean
that it doesn't build.  I'm for the most elegant solution to the problem.
> At some point pkgsrc got GCC_REQD, and my memory is that it was about
> avoiding versions with bugs that tripped on particular packages.  Then
> c++11 happened, and packages started using it before non-c++11 compilers
> faded away.  This hasn't yet been dealt with in a fully organized
> manner.
>
> I think it's wrong to have each package that uses c++11 also have to
> encode GCC_REQD, from an abstraction viewpoint.
I fully agree with this and would rather see a systemic solution than 
one that
modifies a lot of packages.
> There is also the point that for soundness, all c++ programs on a
> machine must be compiled with the same compiler.  (Actually, each
> dependency tree must be compiled with the same compiler, but I don't
> think there are any non-trivial situations where the more complicated
> rule is a net win.  Do you believe that this notion is incorrect?  I ask
> because you are pursuing a path (adding GCC_REQD to individual programs)
> that leads to this problem.
I'm not pursuing that path, in fact I'm hoping to avoid it.
> In your case, as I understand it, you are wanting to use code that is in
> a new language on an operating system that intentionally has old
> software.  This mixing of old and new, in my view, basically does not
> work.  But, with pkgsrc, you can use a new compiler for pkgsrc, and have
> a new world of pkgsrc and the old world of base, more or less
> disconnected from each other (the multi-tree approach above).
>
> I think we should be removing GCC_REQD from packages when the only
> reason is to force a compiler with c++11 or c++14.  GCC_REQD would then
> become unusual.
>
>
> Have you tried putting GCC_REQD in your mk.conf, and rebuilding
> everything?   What's wrong with that approach for you?   That's a
> serious question, because one of the paths forward is to essentially put
> that in the platform file for systems with old compilers.  (Here, I'm
> defining old by "fails to build a non-trivial number of packages that
> need c++11".)   The other path is to add in GCC_REQD=4.8 (or 6) for all
> packages with c++ (not c++11, but any c++, to avoid ABI mixing).  I
> think it's a serious question whether people are better off:
>
>    1) using old system gcc for C and newish pkgsrc gcc for C++
>
>    2) using newish pkgsrc gcc for everything
>
> In favor of 1 is that if you don't want to build C++, you are spared
> building a compiler.  In favor of 2 is that it probably avoids a bunch
> of fairly minor, hard to track down problems that we don't know about.
>
> In asking you if you've tried GCC_REQD=4.8 in mk.conf, I'm basically
> asking you to be a test case for option 2, and if that hurts.  Given
> that you want to build C++ stuff, you have to build the compiler anyway,
> so it seems like it wouldn't be a problem.
I would prefer to use a newer GCC for everything, if it's not too 
painful.  There are no HPC sites that can avoid installing newer 
compilers and many would prefer to use newer compilers for C and Fortran 
as well.  As long as the GCC packages work on CentOS, we would prefer to 
use them.

Thanks,

    JB

--
Earth is a beta site.