Re: CMake builds :)

[Kuba Sunderland-Ober]

>
>
> > I’ll do the copyright assignment and then work on figuratively speaking
> merging the cmake support you’ve done with what I’ve done. I went
> implemented a lot of tests from autotools that were in configure. So
> assuming there is cmake I could get it to work on most any platform.
>
> I don't recommend that, really.  Going this way means the MinGW port
> and the MSVC port will diverge, which is bad for maintenance, since it
> will be impossible to compare them, both in the test suite and in the
> real-life examples.
>

Does GNU infrastructure have what it takes to do builds on Windows, macOS,
Linux, BSD, ...?
If so then github won't be necessary. I don't really intend to ever
maintain it as a separate
port, just to sync the github repo to gnu repo to ensure the tests and
builds pass, and that
release binaries are put out - at least for Windows.

I'd want to do the dev work in personal branches - is it best to do it
using savannah git or
somewhere else? If it's hard to do on savannah then github (or gitlab) is a
necessity, as I
don't have personal CI infrastructure nor care much for running that stuff
locally.

> Regarding the pc directory: yes, that works, but it’s a hack of sorts and
> really only for Mingw.
>
> It isn't only for MinGW.  It used to work for other Windows
> development environments, including Visual Studio (and for OS/2 as
> well).  We removed that because no one was maintaining it.
>

There are real differences between those, and also between MSVC versions,
so some form
of configuration is necessary just to accommodate that. For example, MSVC
2022
supports modern C much better than the previous ones. It also doesn't
provide
globally namespaced non-C-standard APIs in the core runtime library. E.g.
the posix
open is _open, etc. There are defines that bring back this legacy behavior
but they are
deprecated. That's in contrast to mingw, where non-under[lin]ed POSIX-like
API
is available.

My own cmake "port" was developed on mingw and MSVC and the configure
results
do differ between the two, even though it's the same WINAPI that's targeted.

> I’d like it to work out of the box with mingw-gcc, msvc, clang, and icc.
>
> What are the differences, beyond having CC have a different value?
>

The differences are between the results of some configure tests, taken
directly
from configure.ac and autoconf. Don't recall off the top of my head what
exactly
differs, but there's enough difference that having real configuration for
Windows
is just as useful as it is on unices.

> Hey, maybe we can get it to build for msdos again :)
>
> The MSDOS port was removed due to lack of maintenance, so to
> reintroduce it we will need someone who'd volunteer to keep it up to
> date.  Other than that, the same pc/ directory was used for the MSDOS
> build as well, and it worked fine until the moment we removed MSDOS
> support.
>

For MSDOS targeting, it'd have to be cross-compiled most likely,
as keeping a native build going would be probably too much fuss.
At least it wouldn't be me doing it.
But certainly don't mind doing cmake-based cross-compile
for say djgpp and openwatcom v2.

I think the maintenance burden would be eased a lot if there was
a proper CI for all the supported targets. We could start with
things that are easier, like the current BSDs, a couple Linux distros,
OpenVMS, Windows, macOS, illumos (OpenSolaris).

That way at least it'd be trivial to check in a change and see that
nothing broke.

Perhaps there already is CI for all that, but I'm missing it? Savannah
is somewhat tricky to navigate for me.

I have read a lot about the copyright assignment but see no way
to do it solely via an online process. How would I go about it?
Should I download some file, fill out the blanks, PGP-sign it, and
upload/email?

Thanks, Kuba