[gnutls-devel] GnuTLS | add cmake (!1908)

[Read-only notification of GnuTLS library development activities]

Eli Schwartz commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908#note_2268438284


> Tal Regev <https://gitlab.com/tal.regev> commented on a discussion
> <https://gitlab.com/gnutls/gnutls/-/merge_requests/1908#note_2268382047>:
>
> I don't agree it not reviewable. Even this PR is not a renewable (maybe
> this the word you wanted to write) and not give a breakthrough to replace
> the autoconf build system.
>

I'm not sure what you're saying here but I definitely used the word I
intended to use, which is "reviewable" and not "renewable".

I don't know what a "renewable" MR is, but a reviewable MR is one that can
be reviewed by by maintainers and a prerequisite of that is that there is
something available to review.


First it explain the problem to other people.
>

It doesn't explain the problem to other people. The only problem I'm aware
of is that:

- the feature has not been accepted
- a reliance on gnulib means that porting is inherently challenging as you
need to also port gnulib or stop using gnulib

Both are explained sufficiently in the linked issue. Neither are explained
in this MR (using ./configure as part of cmake doesn't demonstrate any
challenge, it simply demonstrates that no attempt was made to implement it).

Assuming I accept for the sake of argument that this MR explains "the
problem", the purpose of an issue is to explain a problem and the purpose
of an MR is to propose a solution. If all this does is explain a problem
and not propose a solution then why isn't this an issue instead?


Second, it covered the other option to do it (in one commit or fork).
>

What is "it" that is being done? This doesn't build gnutls.


Third, it not against other new build system like Meson.
>

At no point did I criticize this MR by saying I would rather meson, so I'm
not sure what you are replying to.


Forth, it give other people a tool to start build and continue this work.
>

I assert my belief that this doesn't provide anything for people to build
on, because this MR doesn't contain any code to build GnuTLS, just
boilerplate that would take a few minutes to reimplement correctly in a
serious attempt to port the real configuration logic over.


If you will think why replace autoconf is not doable, you will end up stay
> with auto conf. But if you really think how you can do it, you will get the
> conclusion that it needed to be build system that will grow along side with
> autoconf.
>

As I've helped several projects move away from autotools I'm quite aware of
how to do it, and you absolutely do need to keep both of them alongside
each other for a while, but the first step *has* to be something that is
actually usable, which this is not. This doesn't even build GnuTLS!

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908#note_2268438284
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20241219/e60cc1b2/attachment.html>