Re: [PATCH 0/2] Integrate Scalar into the CI builds

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

 



Hi Stolee,

On Thu, 2 Jun 2022, Derrick Stolee wrote:

> On 6/2/2022 10:13 AM, Ævar Arnfjörð Bjarmason wrote:
> >
> > On Thu, Jun 02 2022, Derrick Stolee wrote:
> >
> >> On 6/2/2022 5:05 AM, Johannes Schindelin via GitGitGadget wrote:
> >>> Note that the changes to the GitHub workflow are somewhat transient in
> >>> nature: Based on the feedback I received on the Git mailing list, I see some
> >>> appetite for turning Scalar into a full-fledged top-level command in Git,
> >>> similar to gitk. Therefore my current plan is to do exactly that in the end
> >>> (and I already have patches lined up to that end). This will essentially
> >>> revert the ci/run-build-and-tests.sh change in this patch series.
> >>
> >> I expect that this won't be a full remote, since we will still want to
> >> exclude Scalar from the build without INCLUDE_SCALAR enabled.

We had this `INCLUDE_SCALAR` condition in microsoft/git for a while but
since I got the sense that many regulars were in favor of treating
`scalar` like a top-level command (similar to `gitk`), I've since changed
the over-all course to compiling it unconditionally.

The only remnant is the CMake definition, and only in the transitory phase
while Scalar is still in `contrib/scalar/`, and only because I could not
find a better way to encapsulate it.

But yes, if we decide to go with the `INCLUDE_SCALAR` approach, it won't
be a full remove/revert.

> > Scalar (well, scalar.o, not scalar the binary) has been included in the
> > default build (including CI) for a while now.
>
> I'm talking about scalar the binary being important. I'm glad that
> scalar.o has been built already.

These are the raw logs of the `linux-gcc` job of the most recent CI build
of `seen`, as of time of writing:

https://github.com/git/git/commit/7f1978ce8bfe41074df4fc96ff7f2a28e5807fd1/checks/6718714644/logs

When I download those logs and then let my browser search for the term
"scalar", it comes up empty, even if, say, "range-diff.o" is found. Which
is exactly according to my plan: no part of Scalar is to be built unless
explicitly asked for.

The only job that touches it is the `static-analysis` job, which is a bit
unfortunate. But I cannot justify the complexity of the patch it would
take to address that.

In other words: The statement that `scalar.o` is included in the default
build, without any qualifying note about `static-analysis`, is quite
misleading.

Ciao,
Dscho

[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