> On 22 Jul 2026, at 18:48, Nathan Hartman <[email protected]> wrote:
>
> On Wed, Jul 22, 2026 at 12:11 PM Daniel Sahlberg
> <[email protected]> wrote:
>>
>> Den ons 22 juli 2026 kl 17:59 skrev Nathan Hartman
>> <[email protected]>:
>>>
>>> On Wed, Jul 22, 2026 at 11:24 AM Ivan Zhakov <[email protected]> wrote:
>>>>
>>>> On Wed, 22 Jul 2026 at 17:26, Nathan Hartman <[email protected]>
>>>> wrote:
>>>>>
>>>>> On Sat, May 16, 2026 at 3:18 PM Ivan Zhakov <[email protected]> wrote:
>>>>>>
>>>>>> On Sat, 16 May 2026 at 20:19, Nathan Hartman <[email protected]>
>>>>>> wrote:
>>>>>>>
>>>>>>> r1934265 (improving the CMake text in INSTALL) reminded me that CMake
>>>>>>> is not yet mentioned in the 1.15.x Release Notes.
>>>>>>>
>>>>>>> I'd like to add it there--after all, it is a new major (and long-
>>>>>>> requested!) feature in 1.15.x!
>>>>>>
>>>>>> +1!
>>>>>>
>>>>>>>
>>>>>>> But I've lost track of where it is
>>>>>>> currently. Has it reached parity with the autotools build, e.g., being
>>>>>>> able to build all the bindings? Any current limitations I should
>>>>>>> document?
>>>>>>>
>>>>>>
>>>>>> A week ago I created document to summarize features supported by
>>>>>> different Subversion build systems.
>>>>>>
>>>>>> Google Sheet document:
>>>>>> https://docs.google.com/spreadsheets/d/1goa9mrX75RhqQLSsNAr9z6G6cqDvUMDe5xWDJYG99cg/edit?gid=0#gid=0
>>>>>
>>>>>
>>>>> Is this spreadsheet considered the source of truth for the status of
>>>>> the CMake build? If so, can/should I link to it from the Release
>>>>> Notes?
>>>>
>>>>
>>>> I made this document just to show the current state in trunk@HEAD, so I'm
>>>> not sure it fits well in the release notes as-is. I would also say this
>>>> information is too detailed for them.
>>>>
>>>>> Alternatively, we could move this to the CWIKI, or turn it into
>>>>> a HTML table and put it in the release notes directly, or... any other
>>>>> ideas??
>>>>>
>>>>
>>>> One problem with having an external document/wiki page it that it needs to
>>>> be maintained and kept up-to-date, or it will start showing outdated
>>>> information. But if we do want it in the release notes, maybe it could be
>>>> embedded as a plain HTML table. That would match the other parts of the
>>>> release notes and doesn't need updating, because it is a point-in-time
>>>> snapshot.
>>>
>>> If CMake support continues to improve during the course of the 1.15
>>> release line (e.g., adding ability to build the JavaHL bindings,
>>> KWallet/Keyring/Keychain, test with ra_svn/ra_serf, etc.) would we
>>> backport those things to the 1.15.x branch and release them in future
>>> 1.15.x patch releases? That would affect how the table should be
>>> presented, and whether we need to remember to update it.
>>>
>>> For now (in r1936491) I have gone ahead and placed the table in the
>>> 1.15 release notes, so we can see what that would look like. If we
>>> don't like it, we can take it out of there and put it in some other
>>> place. I like DSahlberg's idea of a separate buildsystems.html file,
>>> but then we have to remember to keep it updated. So, we'll see.
>>> Feedback welcome and I'll be happy to revert r1936491 if we don't like
>>> it.
>>>
>>
>> Actually, I like Ivan's idea better... If we backport additional features,
>> we can update the table "from 1.15.2". Having the table in the release
>> notes, we can update it when we release 1.16 to just say "Yes" on anything
>> that was added in a patch release.
>>
>> Only downside is the page is longer than it already was. Does it make sense
>> to hide the table by default and only show it if someone click a link to
>> expand it?
>>
>> (And before somebody cry "NO JAVASCRIPT", we already do this with the menu
>> in narrow-screen layout. It goes something like this: The hamburger is a
>> checkbox and the table is hidden by some CSS class that is dependent on the
>> state of the checkbox. If that is a good idea, I can see if I can remind
>> myself how it works)
>
>
> Well, it sounds like that won't use Javascript, so sure, +1 to that.
>
> Another thing that is lacking: the original Google Docs spreadsheet
> had cell background colors, like green for Yes and red for No. I lost
> all of this formatting when I exported the table to HTML and then
> search-and-replaced stuff in the resulting HTML to match how we do
> tables elsewhere. I wanted to reinstate the colors but it seems we
> don't currently have the CSS for it. I didn't want to just rush in and
> tack on a few more CSS classes in style/site.css, but I also didn't
> want to add CSS tags to every td tag. WDYT?
Just want to mention the html <details> element that might be a viable
alternative.
Thanks,
Thomas Å.
