Re: cmake topics & js/ci-disable-cmake-by-default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:

> I split up the previously merged to "next" ab/cmake-nix-and-ci and
> submitted the uncontroversial parts of it as:

Not gathering any interest by folks who will be affected is
different from being uncontroversial, though.  It may not have seen
any controversy so far, but once it reappears in my tree and
sufficiently advances to cause trouble to other people, it would.

In other words, I am saving time and energy of people by waiting for
positive support on these changes.

> I think whatever happens with js/ci-disable-cmake-by-default that it
> makes sense to pick up & integrate those.

I do not think so at all, at least judging by what little has been
said so far on the list.  Comments on two among these three are
negative ones, and the other one had no traction.

>> * js/ci-disable-cmake-by-default (2022-12-20) 1 commit
>>  - ci: only run win+VS build & tests in Git for Windows' fork
>>
>>  Stop running win+VS build by default.
>>
>>  Will merge to 'next'?
>>  source: <pull.1445.git.1671461414191.gitgitgadget@xxxxxxxxx>
>
> Per my feedback there, I still think it would make sense to at least
> split up the "should we build with MSVC?" from the "do we use cmake, and
> run the re-run tests we already ran with GCC with MSVC too?".

Do you mean that in our primary CI jobs, you would, using Makefile,
want to keep building the win+VS artifacts with MSVC and running the
tests, even though Windows folks want to drive the same build
process via CMake, and their release binaries will come from the
latter?  

I am not sure which extra corners, which matter to us, are covered
by doing so.  What's the upside?

> But now we won't even run that in CI, and "git-for-windows" will have
> ownership of it.
>
> Does that mean that for such Makefile changes we should simply leave out
> the cmake changes, and rely on git-for-windows to "catch up" with its
> cmake contrib component?

That is the natural conclusion of what has been said on the list so
far.  We do not even "rely on"---it is up to them who chose to use
CMake to keep it up to date or lag behind.  Among those who have
made significant contributions and works outside Windows, we found
nobody whowants to touch CMake.

> Ultimately I don't mind such an arrangement, but I think that
> js/ci-disable-cmake-by-default brings us to a weird in-between
> state. Just removing it from the tree and having git-for-windows carry
> it would make sense.

That's fine by me personally, but somebody has to help coordinating
such a move between two projects.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux