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

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

On Wed, Feb 08 2023, Ilya Kantor wrote:

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.

Hi Ævar

On 08/02/2023 11:57, Ævar Arnfjörð Bjarmason wrote:

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

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

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

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.