On 20 Sep, Peter Kovacs wrote:
> 
> Am 20.09.20 um 20:16 schrieb Dave Fisher:
>>> On Sep 20, 2020, at 9:40 AM, Marcus <[email protected]> wrote:
>>>
>>> Am 19.09.20 um 12:36 schrieb Peter Kovacs:
>>>> Keep in mind that C++ Standard has changed a lot in reasoned years,
>>>> and at least I would like to go with the new standard. If we stick
>>>> to the old code for long time it will make maintenance or
>>>>development more difficuilt. yes, that's why I wrote:
>>>
>>> ... keeping the baseline for every OS as long as (technically)
>>>possible ... As long as a compiler exists on that platform that
>>>compiles the older language standard we should not upgrade.
>>
>> I started this thread to discuss build tools and to consider what to
>> do when it becomes difficult to build and have the result work on a
>> minimum platform.
>>
>> My original suggestion is that:
>>
>> (1) 4.1.X always keeps the current OS minimums.
> IMHO we should retire 4.1.X as soon as we have stabilized 4.2.X
>> (2) Should 4.2 branch also keep the current OS minimums or consider
>> more recent OSs as minimums? Is there anything currently on that
>> branch that is a concern?
>>
>> (3) Should we consider more recent OS minimums for trunk which may
>> become 4.5 or 5.0?
> 
> I think we should adjust 4.2.0 but keep trunk the same for now. After 
> release we will have some more fixes to do.
> 
>>
>> What should drive the choice for a more recent minimums? Unavoidable
>> incompatibilities.
> 
> 1) I think we have to work between OSes our user use and the 
> Requirements our dependencies have.
> 
> 2) We have difficulties to update some dependencies since they made a 
> change to c++11 or later standard. In a serious way it would mean we 
> would have to maintain those dependencies or we find a way to backport 
> some C++ features. (i do not have a list.)

The only requirement for C++11 that I've run into is with very recent
versions of vigra.  That's not a depenency that we've ever tried to
upgrade.  I only discovered the issue because of the FreeBSD port, which
was using the system vigra package.  When vigra was updated on FreeBSD,
the port stopped building in C++98 mode, so I switched the port to the
bundled vigra.

The biggest problem I've run into is the lack of C99 support by the old
version of Visual C++ that we use on Windows.  Recent versions of nss
use C99 pretty heavily.  Getting C99 support requires a fairly recent
version of Visual C++.  Microsoft intends that the compiler be used
primarily for compiling C++, so they let the C support lag pretty far
behind.


> 3) Then the SDKs are moved out of maintenance. On Windows our SDK used 
> in the 4.1.X is already not available. On Mac we have a useable SDK 
> 10.10 that let us keep the Lion minimum OS, but the question is how 
> long. Changeing SDKs seems to be a lot of work. We should consider to 
> move away from the verge of availability.
> 
>> Has anyone studied modern Java JDKs and if there is an impact on
>> OpenOffice?
> 
> Mechtilde reported that our build fails on recent Debian due to Java 11.
> 
> 
> My suggestion is:
> 
> Linux: Move to CentOs 7 (As we have already decided)
> 
> MacOSX: Move to 10.10 (And see how much we can move up on the SDK side.
> 
> Windows: Keep WinXP and Move up SDKs as much as possible. (I think 
> latest SDK still supports WinXP target, but I am not sure.)
> 
> 
> All the best
> 
> Peter
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to