With each CI job now using cmake, the autotools configuration setup will
quickly become unusable. This is a proposal to go ahead and remove the auto
tools config from the tree to speed up the planned moves and upcoming
refactoring to the source code. Maintaining two sets of configuration files h
+1
Maintaining both build tools would be very burdensome.
On Thu, Oct 19, 2023 at 10:36 AM Chris McFarlen wrote:
> With each CI job now using cmake, the autotools configuration setup will
> quickly become unusable. This is a proposal to go ahead and remove the auto
> tools config from the tree
I think each company should successfully build their internal version with
cmake before autotools goes away. I don't think Yahoo has done this yet.
On Thu, Oct 19, 2023 at 11:55 AM Brian Neradt
wrote:
> +1
>
> Maintaining both build tools would be very burdensome.
>
> On Thu, Oct 19, 2023 at 10
+1
Goodbye autotools!
On Thursday, October 19, 2023 at 08:55:07 AM PDT, Brian Neradt
wrote:
+1
Maintaining both build tools would be very burdensome.
On Thu, Oct 19, 2023 at 10:36 AM Chris McFarlen wrote:
> With each CI job now using cmake, the autotools configuration setup will
> q
+1 on removing autotools on master. It won’t be tested on PRs and will break
at sometime.
-Bryan
> On Oct 19, 2023, at 8:35 AM, Chris McFarlen wrote:
>
> With each CI job now using cmake, the autotools configuration setup will
> quickly become unusable. This is a proposal to go ahead and
+1
Actually, autotools build is already broken by recent changes (at
least on my macOS with LLVM16).
```
» ./configure
...
configure: creating ./config.status
config.status: error: cannot find input file: `Makefile.in'
```
— Masaori
On Fri, Oct 20, 2023 at 12:36 AM Chris McFarlen wrote:
>
> Wi
Could you please summarize the current state of the cmake work?
Is there any documentation for users of how to switch from autotools to cmake?
Are there any autotools build features that are not supported in cmake?
FWIW I have builds that are using
--prefix
--with-user
--
