CMakeLists.txt from contrib/buildsystems fails to build on Mac

CMakeLists.txt from contrib/buildsystems fails to build on Mac

[Ilya Kantor]

Hello,

I've just tried to build git as described in contrib/buildsystems/CMakeLists.txt, and it doesn't work.

Is this route supposed to work at all?

I'm on MacOS Ventura,
first running this:
```
mkdir -p contrib/buildsystems/out
cd contrib/buildsystems/out
cmake ../ -DCMAKE_BUILD_TYPE=Release
```

This works fine (the full output is here: https://gist.github.com/11f6786eb195a4bc939e010d4f759a22).

And then I run `make`:

```
make
```

Although it dies with an error.

The full output is here: https://gist.github.com/24e2eb21613668c44d81f6f0cc78e1a1

Here's the ending error:

```
/opt/tmp/git/read-cache.c:170:22: error: no member named 'st_ctim' in 'struct stat'
        sd->sd_ctime.nsec = ST_CTIME_NSEC(*st);
                            ^~~~~~~~~~~~~~~~~~
/opt/tmp/git/contrib/buildsystems/../../git-compat-util.h:1380:48: note: expanded from macro 'ST_CTIME_NSEC'
#define ST_CTIME_NSEC(st) ((unsigned int)((st).st_ctim.tv_nsec))
                                          ~~~~ ^
/opt/tmp/git/read-cache.c:171:22: error: no member named 'st_mtim' in 'struct stat'
        sd->sd_mtime.nsec = ST_MTIME_NSEC(*st);
                            ^~~~~~~~~~~~~~~~~~
/opt/tmp/git/contrib/buildsystems/../../git-compat-util.h:1381:48: note: expanded from macro 'ST_MTIME_NSEC'
#define ST_MTIME_NSEC(st) ((unsigned int)((st).st_mtim.tv_nsec))
                                          ~~~~ ^
/opt/tmp/git/read-cache.c:2410:27: error: no member named 'st_mtim' in 'struct stat'
        istate->timestamp.nsec = ST_MTIME_NSEC(st);
                                 ^~~~~~~~~~~~~~~~~
/opt/tmp/git/contrib/buildsystems/../../git-compat-util.h:1381:48: note: expanded from macro 'ST_MTIME_NSEC'
#define ST_MTIME_NSEC(st) ((unsigned int)((st).st_mtim.tv_nsec))
                                          ~~~~ ^
/opt/tmp/git/read-cache.c:3177:27: error: no member named 'st_mtim' in 'struct stat'
        istate->timestamp.nsec = ST_MTIME_NSEC(st);
                                 ^~~~~~~~~~~~~~~~~
/opt/tmp/git/contrib/buildsystems/../../git-compat-util.h:1381:48: note: expanded from macro 'ST_MTIME_NSEC'
#define ST_MTIME_NSEC(st) ((unsigned int)((st).st_mtim.tv_nsec))
                                          ~~~~ ^
4 errors generated.
make[2]: *** [CMakeFiles/libgit.dir/opt/tmp/git/read-cache.c.o] Error 1
make[1]: *** [CMakeFiles/libgit.dir/all] Error 2
```

May that be because of some changes in MacOs Ventura? 
Or is the CMakeLists.txt "dead and forgotten"? ;)

P.S. The regular "make" route works.

Kind regards,
Ilya Kantor

Re: CMakeLists.txt from contrib/buildsystems fails to build on Mac

[Ævar Arnfjörð Bjarmason]

On Wed, Feb 08 2023, Ilya Kantor wrote:

> May that be because of some changes in MacOs Ventura? 
> Or is the CMakeLists.txt "dead and forgotten"? ;)
>
> P.S. The regular "make" route works.

You should just use "make", the "cmake" build method is currently in
some limbo. See my
https://lore.kernel.org/git/221227.86pmc4vrk3.gmgdl@evledraar.gmail.com/
for a recent overview/questions about it.

Since I wrote that 0949eba7fd0 (diagnose: another dup2() leak,
2022-12-06) landed on git.git's master, so we don't run it ourselves in
CI, even for Windows (which it was intended for).

As noted in previous exchanges I wouldn't mind fixing it up to work on
more platforms, but Junio wasn't enthusiastic about those patches &
dropped them.

Alternatively I think the best thing to do is to "git rm" it from
git.git, and leave it to git-for-windows. From what I understood from
Johannes he preferred that plan.

Or rather, that GFW would be fixing it up, but then I don't see why it
should be in git.git, which as your message shows just leads to
confusion about why this component is in git.git's tree.

Re: CMakeLists.txt from contrib/buildsystems fails to build on Mac

[Phillip Wood]

Hi Ævar

On 08/02/2023 11:57, Ævar Arnfjörð Bjarmason wrote:
> Or rather, that GFW would be fixing it up, but then I don't see why it
> should be in git.git, which as your message shows just leads to
> confusion about why this component is in git.git's tree.

I think Ilya's message shows we need to update the instructions in 
CMakeLists.txt to make it clear it is Windows only.

Best Wishes

Phillip

Re: CMakeLists.txt from contrib/buildsystems fails to build on Mac

[Ilya Kantor]

Hi,

Thank you for the responses.

Yes, I saw the discussion, but couldn't figure out the final outcome.

Indeed, I'd suggest to remove the mention of any other platforms if it's windows-only.

And if it's windows-only, then it makes sense to move it to git-for-windows, at least for a bird's-eye view.

Kind regards,
Ilya Kantor

> On 8 Feb 2023, at 15:31, Phillip Wood <phillip.wood123@gmail.com> wrote:
> 
> Hi Ævar
> 
> On 08/02/2023 11:57, Ævar Arnfjörð Bjarmason wrote:
>> Or rather, that GFW would be fixing it up, but then I don't see why it
>> should be in git.git, which as your message shows just leads to
>> confusion about why this component is in git.git's tree.
> 
> I think Ilya's message shows we need to update the instructions in CMakeLists.txt to make it clear it is Windows only.
> 
> Best Wishes
> 
> Phillip

Re: CMakeLists.txt from contrib/buildsystems fails to build on Mac

[Junio C Hamano]

Phillip Wood <phillip.wood123@gmail.com> writes:

> On 08/02/2023 11:57, Ævar Arnfjörð Bjarmason wrote:
>> Or rather, that GFW would be fixing it up, but then I don't see why it
>> should be in git.git, which as your message shows just leads to
>> confusion about why this component is in git.git's tree.
>
> I think Ilya's message shows we need to update the instructions in
> CMakeLists.txt to make it clear it is Windows only.

That matches the conclusion in the thread

  https://lore.kernel.org/git/1e701a54-0356-9f55-ab53-9d8bfdd93e55@dunelm.org.uk/

which was a subthread of the primary discussion we had on this
topic, which starts here:

  https://lore.kernel.org/git/544fff8a-7d56-57a1-00a3-d1a9302e227c@dunelm.org.uk/

I am fine with either marking CMakeLists as windows-only, or
removing it from my tree and have GfW folks add it back to their
tree.

Or keep it in my tree, make CI failures around it "soft" failures,
and mark it prominently as "work in progress" on platforms other
than Windows.  But this choice is only valid if we as the project
want to expend more effort on enhancing and extending cmake support.
I personally do not believe in having to maintain two parallel build
systems for non Windows and keep them in sync.