On Thu, Jun 12, 2025 at 11:29 AM Daniel Sahlberg <
daniel.l.sahlb...@gmail.com> wrote:
> Den tors 12 juni 2025 kl 09:16 skrev Branko Čibej <br...@apache.org>:
>
>> On 12. 6. 25 00:30, Timofei Zhakov wrote:
>>
>> Revert most of the changes in svn_utf.h from r1926293. Instead, tell the
>>> CMake build to expose APR and APR-Util include paths everywhere.
>>>
>>> (...)
>>
>>>
>>> * CMakeLists.txt: Add APR and APR-Util include paths to the top-level
>>> directory properties.
>>>
>>
>> (...)
>>
>>
>>> --- subversion/trunk/CMakeLists.txt (original)
>>> +++ subversion/trunk/CMakeLists.txt Wed Jun 11 15:40:43 2025
>>> @@ -289,6 +289,12 @@ else()
>>> endif()
>>> endif()
>>>
>>> +# APR and APR-Util include directories must be available to all our
>>> souroces,
>>> +# not just those that happen to link with one or the other of these
>>> libraries.
>>> +get_target_property(_apr_include external-apr
>>> INTERFACE_INCLUDE_DIRECTORIES)
>>> +get_target_property(_apu_include external-aprutil
>>> INTERFACE_INCLUDE_DIRECTORIES)
>>> +include_directories(${_apr_include} ${_apu_include})
>>> +
>>>
>>
>> This is wrong. You can't modify global include directories of the entire
>> project to force it to use apr everywhere. This is a hack, not a fix.
>>
>>
>>
>> This is how the autotools build works. This is what the build.conf
>> dependency declarations expect. This is what our code expects, because APR
>> is part of our public interface. If you want to do it some other way that
>> has the same effect, go ahead. I've had it with your "this is wrong" and
>> "that is wrong" and making changes with no thought about context.
>>
>> -- Brane
>>
>
> Hi guys,
>
> I think the tone on-list lately has been going the wrong way lately -
> maybe it is because I'm not a native English speaker and I'm not very good
> at identifying what may be intended as a joke - but it seems way to harsh
> for me at the moment.
>
Sorry 👉👈
> "this is wrong" doesn't really help (and I believe it has been said from
> both sides) - on the other hand "I've had it" isn't much better.
>
True.
Can we please step back for one moment and assume best intentions? Things
> doesn't need to move at lightning speed - especially not on trunk. On the
> other hand, we've not seen much development at all the last few years so
> I'm really keen on making sure things actually MOVE. If things break - well
> we can fix it, can't we?\
>
Makes sense to me.
My opinion is that by adding new things, especially in the case of cmake,
may easily turn our code base into a mess of all that stuff we've added.
Subversion is implemented very nicely in terms of keeping proper
abstraction and code style, I'd call it. I mean it's the perfect example of
how such projects should be like.
I've designed cmake support to succisfy to those standards. And now I'm
trying my best to maintain the same. This is why I could be that critical
to such things.
I hope this explains my reaction and pain I could experience. Sorry.
(I'm answering the following emails soonly)
--
Timofei Zhakov 😻
