{"thread":{"id":"62110","subject":"./configure fails to link test program due to missing dependencies","startedAt":"2024-09-14T22:57:41Z","lastAt":"2024-09-30T16:31:06Z","messageCount":31,"participants":["Henrik Holst","Junio C Hamano","brian m. carlson","Patrick Steinhardt","Phillip Wood","Eli Schwartz","Paul Smith","phillip.wood123@gmail.com","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"502797","messageId":"GV1PR02MB848925A79A9DD733848182D58D662@GV1PR02MB8489.eurprd02.prod.outlook.com","threadId":"62110","inReplyTo":null,"subject":"./configure fails to link test program due to missing dependencies","fromName":"Henrik Holst","fromEmail":"henrik.holst@outlook.com","sentAt":"2024-09-14T22:57:39Z","receivedAt":"2024-09-14T22:57:41Z","isPatch":false,"sender":{"key":"henrik.holst@outlook.com","avatar":null},"body":"Hej and hello!\n\nI am tinkering with LFS 12.1 and I ran into a problem to compile git 2.44.0 with https/curl support due to an error in the ./configure script for the libcurl detection.\n\nThe relevant section of config.log:\n\nconfigure:5462: checking for curl_global_init in -lcurl\nconfigure:5485: gcc -o conftest -g -O2   conftest.c -lcurl   >&5\n/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../lib/libcurl.a(libcurl_la-content_encoding.o): in function `zstd_do_close':\ncontent_encoding.c:(.text+0x78): undefined reference to `ZSTD_freeDStream'\n/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../lib/libcurl.a(libcurl_la-content_encoding.o): in function `zstd_do_write':\ncontent_encoding.c:(.text+0x112): undefined reference to `ZSTD_decompressStream'\n/usr/bin/ld: content_encoding.c:(.text+0x11a): undefined reference to `ZSTD_isError'\n...\n\nIf I set LDFLAGS to whatever pkg-config --libs libcurl says on my system (actually: -lcurl -lssl -lcrypto -lzstd -lbrotlidec -lz) then it compiles just fine. If I add LDFLAGS to the configure environment it will accept that test, and then detect, as expected, the pkg-config settings for libcurl.\n\nShould not ./configure FIRST check for a pkg-config environment without assuming that even the most trivial curl programs should compile without any additional dependencies like zstd etc?\n\nThank you for your help and have a great weekend!\n\nHenrik Holst\n\n[System Info]\ngit version:\ngit version 2.44.0\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\ncompiler info: gnuc: 13.2\nlibc info: glibc: 2.39\n$SHELL (typically, interactive shell): /usr/bin/fish\n\n\n[Enabled Hooks]\nnot run from a git repository - no hooks to show"},{"id":"502813","messageId":"xmqqldzsrhyp.fsf@gitster.g","threadId":"62110","inReplyTo":"GV1PR02MB848925A79A9DD733848182D58D662@GV1PR02MB8489.eurprd02.prod.outlook.com","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-15T16:37:34Z","receivedAt":"2024-09-15T16:37:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Henrik Holst writes:\n\n> If I set LDFLAGS to whatever pkg-config --libs libcurl says on my system (actually: -lcurl -lssl -lcrypto -lzstd -lbrotlidec -lz) then it compiles just fine. If I add LDFLAGS to the configure environment it will accept that test, and then detect, as expected, the pkg-config settings for libcurl.\n>\n> Should not ./configure FIRST check for a pkg-config environment without assuming that even the most trivial curl programs should compile without any additional dependencies like zstd etc?\n\nLooking at configure.ac, pkg-config is not used for any package.\nSpecifically for curl, it seems that \"curl-config --libs\" is used.\n\nPresumably the reason behind the current behaviour is combination of\n(1) ./configure is an after-thought in the build infrastructure for\nthis project, (2) pkg-config was not ubiquitous back when autoconf\nsupport was written for this project, and (3) nobody considered\n\"upgrading\" our use of \"curl-config\" and our manual detection of\ndependency detection for other libraries to just use \"pkg-config\".\n\nPatches welcome ;-)\n\nThanks.\n"},{"id":"502814","messageId":"ZucPpLL3Q5SkVfW1@tapette.crustytoothpaste.net","threadId":"62110","inReplyTo":"xmqqldzsrhyp.fsf@gitster.g","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-09-15T16:47:32Z","receivedAt":"2024-09-15T16:47:34Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-09-15 at 16:37:34, Junio C Hamano wrote:\n> Henrik Holst writes:\n> \n> > If I set LDFLAGS to whatever pkg-config --libs libcurl says on my system (actually: -lcurl -lssl -lcrypto -lzstd -lbrotlidec -lz) then it compiles just fine. If I add LDFLAGS to the configure environment it will accept that test, and then detect, as expected, the pkg-config settings for libcurl.\n> >\n> > Should not ./configure FIRST check for a pkg-config environment without assuming that even the most trivial curl programs should compile without any additional dependencies like zstd etc?\n> \n> Looking at configure.ac, pkg-config is not used for any package.\n> Specifically for curl, it seems that \"curl-config --libs\" is used.\n> \n> Presumably the reason behind the current behaviour is combination of\n> (1) ./configure is an after-thought in the build infrastructure for\n> this project, (2) pkg-config was not ubiquitous back when autoconf\n> support was written for this project, and (3) nobody considered\n> \"upgrading\" our use of \"curl-config\" and our manual detection of\n> dependency detection for other libraries to just use \"pkg-config\".\n\nI'll also note that the traditional expectation is that users are using\ndynamic libraries, where this would have worked because libcurl would\nhave been linked against all its dependencies, and not static libraries,\nwhere all dependencies must be specified explicitly.\n\nYou almost certainly don't want to statically link libcurl or OpenSSL\nbecause you'll have a security issue as soon as one of those packages\nissues a security update, which will require that you recompile Git to\napply the update. With dynamic libraries, security updates are applied\nas soon as a new process is spawned.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"502833","messageId":"ZufjWR6AJM-DIWPR@pks.im","threadId":"62110","inReplyTo":"xmqqldzsrhyp.fsf@gitster.g","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-09-16T07:50:49Z","receivedAt":"2024-09-16T07:50:55Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Sun, Sep 15, 2024 at 09:37:34AM -0700, Junio C Hamano wrote:\n> Henrik Holst writes:\n> \n> > If I set LDFLAGS to whatever pkg-config --libs libcurl says on my system (actually: -lcurl -lssl -lcrypto -lzstd -lbrotlidec -lz) then it compiles just fine. If I add LDFLAGS to the configure environment it will accept that test, and then detect, as expected, the pkg-config settings for libcurl.\n> >\n> > Should not ./configure FIRST check for a pkg-config environment without assuming that even the most trivial curl programs should compile without any additional dependencies like zstd etc?\n> \n> Looking at configure.ac, pkg-config is not used for any package.\n> Specifically for curl, it seems that \"curl-config --libs\" is used.\n> \n> Presumably the reason behind the current behaviour is combination of\n> (1) ./configure is an after-thought in the build infrastructure for\n> this project, (2) pkg-config was not ubiquitous back when autoconf\n> support was written for this project, and (3) nobody considered\n> \"upgrading\" our use of \"curl-config\" and our manual detection of\n> dependency detection for other libraries to just use \"pkg-config\".\n\nI sometimes wonder whether we should move on and discard one of the\nthree build systems we have: plain GNU Make, autoconf and CMake. And\nfrom these three I'd rather want to throw the autoconf-based thing away:\n\n - The Makefile is probably what most people use, so throwing it out is\n a no-go right now.\n\n - CMake is really useful because it has support for IDEs and\n alternatives to GNU Make like Ninja, which builds Git way faster\n than Makefiles. It also has support for out-of-tree builds, which I\n find rather useful.\n\nSo is there a path forward to move CMake support out of contrib/, make\nit an officially supported way to build Git and then throw away the\nautoconf-based infra? I'm not the biggest fan of CMake myself and very\nmuch prefer Meson, but we already have it wired up and thus I'm trying\nto be at least a bit pragmatic.\n\n(I'd honestly prefer to end up with a single build system, but also\nthrowing our Makefiles out would be a step too far at this point in\ntime.)\n\nPatrick\n"},{"id":"502993","messageId":"29c5c9c0-aa61-415a-9cfa-d64a6b946a48@gmail.com","threadId":"62110","inReplyTo":"ZufjWR6AJM-DIWPR@pks.im","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-09-18T10:04:54Z","receivedAt":"2024-09-18T10:04:57Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Patrick\n\nOn 16/09/2024 08:50, Patrick Steinhardt wrote:\n> \n> I sometimes wonder whether we should move on and discard one of the\n> three build systems we have: plain GNU Make, autoconf and CMake. And\n> from these three I'd rather want to throw the autoconf-based thing away:\n> \n> - The Makefile is probably what most people use, so throwing it out is\n> a no-go right now.\n> \n> - CMake is really useful because it has support for IDEs and\n> alternatives to GNU Make like Ninja, which builds Git way faster\n> than Makefiles. It also has support for out-of-tree builds, which I\n> find rather useful.\n> \n> So is there a path forward to move CMake support out of contrib/, make\n> it an officially supported way to build Git and then throw away the\n> autoconf-based infra? I'm not the biggest fan of CMake myself and very\n> much prefer Meson, but we already have it wired up and thus I'm trying\n> to be at least a bit pragmatic.\n\nWe seem to get fairly regular bug reports about the configure script, \npresumably because most contributors are using the Makefile. It would \ncertainly be nice if we could get the CMake support into a state where \nwe could consider dropping the configure script.\n\nBest Wishes\n\nPhillip\n"},{"id":"503032","messageId":"xmqqy13oa8oe.fsf@gitster.g","threadId":"62110","inReplyTo":"29c5c9c0-aa61-415a-9cfa-d64a6b946a48@gmail.com","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-18T22:39:13Z","receivedAt":"2024-09-18T22:39:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n> We seem to get fairly regular bug reports about the configure script,\n> presumably because most contributors are using the Makefile. It would\n> certainly be nice if we could get the CMake support into a state where\n> we could consider dropping the configure script.\n\nWhile I would agree that two is better than having to support three\nbuild procedures, I am not sure how improvement of CMake support\nneeds to be a prerequisite for removal of autoconf.\n\n\n\n"},{"id":"503347","messageId":"ZvKsH1Ct-YwBPA_f@pks.im","threadId":"62110","inReplyTo":"xmqqy13oa8oe.fsf@gitster.g","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-09-24T12:10:14Z","receivedAt":"2024-09-24T12:10:13Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Wed, Sep 18, 2024 at 03:39:13PM -0700, Junio C Hamano wrote:\n> Phillip Wood writes:\n> \n> > We seem to get fairly regular bug reports about the configure script,\n> > presumably because most contributors are using the Makefile. It would\n> > certainly be nice if we could get the CMake support into a state where\n> > we could consider dropping the configure script.\n> \n> While I would agree that two is better than having to support three\n> build procedures, I am not sure how improvement of CMake support\n> needs to be a prerequisite for removal of autoconf.\n\nI'm mostly coming from the angle that autoconf is likely used by systems\nthat are not perfectly supported by our current, static configuration. I\ndon't want to make the life of such system integrators harder by having\nto figure out what kind of arcane functions they have to set manually\nnow to make things build on their platform again.\n\nI'm not really sure whether distros _do_ actually use autoconf. Checking\na few distros:\n\n - Arch doesn't.\n - Cygwin uses autoconf.\n - Debian doesn't.\n - FreeBSD uses autoconf.\n - Gentoo doesn't.\n - NixOS uses autoconf.\n - OpenBSD uses autoconf.\n - Ubuntu doesn't.\n\nSo basically, we'd be making the life harder of anybody who doesn't\nconform to the \"standard\" way of doing things in Linux, which I think is\nnot exactly a nice thing to do.\n\nAnd that's why I think we should have an alternative way to configure\nand build Git that can act as a replacement for autoconf, with my vote\ngoing to either CMake or Meson. They are a proper replacement for\nautoconf that makes the downstream maintainer's jobs easier while also\nbringing additional features to the table that we don't currently have.\n\nEli makes a couple of good remarks in [1] about things that both CMake\nand Meson bring to the table in addition to that, while also mentioning\nsome of the benefits of Meson over CMake.\n\nI would be okay to make Git work with such a build system myself. The\ncurrent CMake build instructions can be used to _build_ Git, but AFAIU\nthey cannot yet run the Git test suite. Dscho pointed me to a couple of\npatches from Ævar that work into this direction, and I'd be happy to\nrevive them. I'd also be okay with picking Meson over CMake if that is\nwhat people want. But my ultimate goal would then be that we have at\nleast one CI job build and test against such a build system and give it\nthe \"official blessing\" as an alternative way to build Git.\n\n[1]: <0864bd25-d5c4-45ac-a59e-e6f7d24002de@gentoo.org>\n\nPatrick\n"},{"id":"503358","messageId":"b6b131cb-683c-4140-9769-290b622721e1@gentoo.org","threadId":"62110","inReplyTo":"ZvKsH1Ct-YwBPA_f@pks.im","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Eli Schwartz","fromEmail":"eschwartz@gentoo.org","sentAt":"2024-09-24T13:59:52Z","receivedAt":"2024-09-24T13:59:56Z","isPatch":false,"sender":{"key":"eschwartz@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/6551424?v=4"},"body":"On 9/24/24 8:10 AM, Patrick Steinhardt wrote:\n\nThanks for the CC to this interesting thread. :)\n\n\n> On Wed, Sep 18, 2024 at 03:39:13PM -0700, Junio C Hamano wrote:\n>> Phillip Wood writes:\n>>\n>>> We seem to get fairly regular bug reports about the configure script,\n>>> presumably because most contributors are using the Makefile. It would\n>>> certainly be nice if we could get the CMake support into a state where\n>>> we could consider dropping the configure script.\n>>\n>> While I would agree that two is better than having to support three\n>> build procedures, I am not sure how improvement of CMake support\n>> needs to be a prerequisite for removal of autoconf.\n> \n> I'm mostly coming from the angle that autoconf is likely used by systems\n> that are not perfectly supported by our current, static configuration. I\n> don't want to make the life of such system integrators harder by having\n> to figure out what kind of arcane functions they have to set manually\n> now to make things build on their platform again.\n> \n> I'm not really sure whether distros _do_ actually use autoconf. Checking\n> a few distros:\n> \n> - Arch doesn't.\n> - Cygwin uses autoconf.\n> - Debian doesn't.\n> - FreeBSD uses autoconf.\n> - Gentoo doesn't.\n> - NixOS uses autoconf.\n> - OpenBSD uses autoconf.\n> - Ubuntu doesn't.\n> \n> So basically, we'd be making the life harder of anybody who doesn't\n> conform to the \"standard\" way of doing things in Linux, which I think is\n> not exactly a nice thing to do.\n\n\nI think we'd probably like to use the configure script rather than the\nraw Makefile, if the configure script was supported.\n\nIt would fix things like git failing to cross-compile because\ncurl-config doesn't work for that, assuming that --\n\nOh yeah, the configure script isn't maintained well and doesn't use\npkg-config. :)\n\nSee e.g. https://bugs.gentoo.org/738218 which mentions pkg-config, even.\n\n\n> And that's why I think we should have an alternative way to configure\n> and build Git that can act as a replacement for autoconf, with my vote\n> going to either CMake or Meson. They are a proper replacement for\n> autoconf that makes the downstream maintainer's jobs easier while also\n> bringing additional features to the table that we don't currently have.\n\n\nLet's say, rather, that they are an alternative for autoconf. And one of\nthe good qualities of them as an alternative for autoconf is that you\ncan actually build on Windows, without needing a mingw toolchain to run\na shell script.\n\nAn actually maintained autoconf script makes the downstream maintainer's\njob easier in all cases...\n\n... and also makes the upstream maintainer's job easier in some ways and\nharder in other ways, because autoconf is hard/annoying to get right as\na maintainer. This is due to the complexities of m4 and mixing that\ninline into \"m4sh\" -- which was a logical tradeoff in the past, when\nWindows wasn't as relevant and the GNU project wanted to design a build\nsystem that maximized the benefits for end users, including \"do not need\nto install any software to run ./configure\", even if that sometimes\nmeant making maintainers' jobs harder. I've never seen a project with a\n*well-maintained, correctly written* autotools build system where the\n*unix* end users had complaints about the use of autotools. The\ncomplaint is inevitably that autotools wasn't correctly used\n\nStill I would prefer meson over autotools any day of the week. I'd also\nprefer autotools over cmake, mind you.\n\n\n> Eli makes a couple of good remarks in [1] about things that both CMake\n> and Meson bring to the table in addition to that, while also mentioning\n> some of the benefits of Meson over CMake.\n> \n> I would be okay to make Git work with such a build system myself. The\n> current CMake build instructions can be used to _build_ Git, but AFAIU\n> they cannot yet run the Git test suite. Dscho pointed me to a couple of\n> patches from Ævar that work into this direction, and I'd be happy to\n> revive them. I'd also be okay with picking Meson over CMake if that is\n> what people want. But my ultimate goal would then be that we have at\n> least one CI job build and test against such a build system and give it\n> the \"official blessing\" as an alternative way to build Git.\n\n\nLike, erm, many people :D I spend vast portions of my day inside git. I\nam not very good at C, though -- and the likelihood of git being\ncompletely rewritten in python is quite low -- so I generally do not try\nvery hard to repay that by getting involved in git development (I have\nsome humble patches consisting of a single patch series, which I do feel\npretty proud of since it enabled a very useful workflow, but still:\nultimately amounts to a one-off event).\n\nI do know build systems pretty well though! :) And I'd be happy to\ncollaborate on Meson and help maintain the build system support in the\nlong term, assuming the consensus is that people think it would be a\nneat idea to add meson support (regardless of whether it serves as a\nprimary or secondary build system).\n\n\nAlthough I'm uninterested in personally working on cmake, as you\nprobably predicted.\n\n\n-- \nEli Schwartz\nGentoo Developer and Meson Build maintainer\n"},{"id":"503361","messageId":"1e0074769f43f5a1f4938e74015b8903642d6b03.camel@mad-scientist.net","threadId":"62110","inReplyTo":"b6b131cb-683c-4140-9769-290b622721e1@gentoo.org","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Paul Smith","fromEmail":"paul@mad-scientist.net","sentAt":"2024-09-24T14:25:07Z","receivedAt":"2024-09-24T14:25:17Z","isPatch":false,"sender":{"key":"paul@mad-scientist.net","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"On Tue, 2024-09-24 at 09:59 -0400, Eli Schwartz wrote:\n> Still I would prefer meson over autotools any day of the week. I'd\n> also prefer autotools over cmake, mind you.\n\nJust to point out that relying on ever-more-esoteric build tools is a\nrecipe for frustration for those of us who want to build from source. \nYes, I know meson is somewhat popular and definitely has a following,\nbut in the grand scheme of things it's still rare to find projects\nrequiring it, especially at the base level of software. I build a lot\nof software and I have never once had to install it, for example.\n\nI maintain a minimalist set of tools and libraries that we compile\nlocally from source so we can control the full toolchain. Every time a\npackage we want to add requires some new, different build tool it's a\nmassive annoyance. As of today everything builds with either make or\ncmake (mainly for Windows support).\n\nOn the other hand, now that all the systems we use have \"good enough\"\nnative versions of Git we have stopped building it in our environment.\nSo in that sense it no longer matters to me directly :).\n"},{"id":"503362","messageId":"b28b1256-01bc-46a3-8338-e47f2301eccf@gmail.com","threadId":"62110","inReplyTo":"xmqqldzsrhyp.fsf@gitster.g","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Eli Schwartz","fromEmail":"eschwartz93@gmail.com","sentAt":"2024-09-24T14:31:08Z","receivedAt":"2024-09-24T14:31:12Z","isPatch":false,"sender":{"key":"eschwartz93@gmail.com","avatar":"https://gravatar.com/avatar/80b459bb75c0edb5e116884705adb9095fbd01cbbf91cb29a9ed23577fff7d34?d=mp&s=160"},"body":"On 9/15/24 12:37 PM, Junio C Hamano wrote:\n> Looking at configure.ac, pkg-config is not used for any package.\n> Specifically for curl, it seems that \"curl-config --libs\" is used.\n> \n> Presumably the reason behind the current behaviour is combination of\n> (1) ./configure is an after-thought in the build infrastructure for\n> this project, (2) pkg-config was not ubiquitous back when autoconf\n> support was written for this project, and (3) nobody considered\n> \"upgrading\" our use of \"curl-config\" and our manual detection of\n> dependency detection for other libraries to just use \"pkg-config\".\n> \n> Patches welcome ;-)\n\n\nAs an aside: I am skeptical of this explanation.\n\npkg-config's first git commit in 2005 is an import of a 2001 commit from\nanother version control system (probably GNU Arch -- author \"Arch\nLibrarian\"). The changelog it includes starts a year earlier, in 2000.\nWikipedia agrees, claiming the initial release of pkg-config was in 2000\nand citing gtk-devel mailing list discussions from June of that year.\n\ngit added a configure.ac script 6 years later. Curl itself had installed\na .pc file for 7 months at that time, and OpenSSL had installed one for\nnearly 4 years.\n\nBut git's configure script looked -- and still looks -- for -lcurl only\nto set NO_CURL for the Makefile. In 2018, ./configure started using\ncurl-config, in order to set CURL_LDFLAGS.\n\nI suppose it was copied by rote from the Makefile, which has less\nflexibility to try pkg-config and fall back to curl-config.\n\nPart 1 of the explanation is valid: ./configure was an after-thought. :)\n\n\n-- \nEli Schwartz\nGentoo Developer and Meson Build maintainer\n"},{"id":"503383","messageId":"xmqqwmj1t0hp.fsf@gitster.g","threadId":"62110","inReplyTo":"ZvKsH1Ct-YwBPA_f@pks.im","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-24T17:39:14Z","receivedAt":"2024-09-24T17:39:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt writes:\n\n> I'm not really sure whether distros _do_ actually use autoconf. Checking\n> a few distros:\n>\n> - Arch doesn't.\n> - Cygwin uses autoconf.\n> - Debian doesn't.\n> - FreeBSD uses autoconf.\n> - Gentoo doesn't.\n> - NixOS uses autoconf.\n> - OpenBSD uses autoconf.\n> - Ubuntu doesn't.\n>\n> So basically, we'd be making the life harder of anybody who doesn't\n> conform to the \"standard\" way of doing things in Linux, which I think is\n> not exactly a nice thing to do.\n\nIf we stopped shipping configure (in our tarballs) and configure.in\n(in the sources), would distros in the above list that do currently\nuse autoconf be able to build purely by having reasonable setting in\nconfig.mak.uname already?\n\n> And that's why I think we should have an alternative way to configure\n> and build Git that can act as a replacement for autoconf, with my vote\n> going to either CMake or Meson.\n\nI guess the above question from me is a semi- tongue-in-cheek vote\nfor config.mak.uname as that alternative way.\n\n> They are a proper replacement for autoconf that makes the\n> downstream maintainer's jobs easier while also bringing additional\n> features to the table that we don't currently have.\n>\n> Eli makes a couple of good remarks in [1] about things that both CMake\n> and Meson bring to the table in addition to that, while also mentioning\n> some of the benefits of Meson over CMake.\n>\n> I would be okay to make Git work with such a build system myself. The\n> current CMake build instructions can be used to _build_ Git, but AFAIU\n> they cannot yet run the Git test suite. Dscho pointed me to a couple of\n> patches from Ævar that work into this direction, and I'd be happy to\n> revive them. I'd also be okay with picking Meson over CMake if that is\n> what people want. But my ultimate goal would then be that we have at\n> least one CI job build and test against such a build system and give it\n> the \"official blessing\" as an alternative way to build Git.\n\nI already said that having to support two is better than having to\nsupport three in another thread ;-). If adding the fourth would\nallow us to drop all other three eventually, that would be nice.\n\nOur dependance of heavy use of GNU-ism in our Makefiles makes an\nargument that make is the common denominator a fairly weak one, so\nthe single one that eventually we use does not have to be \"make\",\nbut it has to be something available widely and easy to learn.\n\nThanks.\n\n"},{"id":"503454","messageId":"ZvOTL0cG8qRY8OXe@pks.im","threadId":"62110","inReplyTo":"b6b131cb-683c-4140-9769-290b622721e1@gentoo.org","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-09-25T04:36:06Z","receivedAt":"2024-09-25T04:36:14Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Tue, Sep 24, 2024 at 09:59:52AM -0400, Eli Schwartz wrote:\n> On 9/24/24 8:10 AM, Patrick Steinhardt wrote:\n> Still I would prefer meson over autotools any day of the week. I'd also\n> prefer autotools over cmake, mind you.\n\nIs that a typo or do you really prefer autotools over CMake? :)\n\n> > Eli makes a couple of good remarks in [1] about things that both CMake\n> > and Meson bring to the table in addition to that, while also mentioning\n> > some of the benefits of Meson over CMake.\n> > \n> > I would be okay to make Git work with such a build system myself. The\n> > current CMake build instructions can be used to _build_ Git, but AFAIU\n> > they cannot yet run the Git test suite. Dscho pointed me to a couple of\n> > patches from Ævar that work into this direction, and I'd be happy to\n> > revive them. I'd also be okay with picking Meson over CMake if that is\n> > what people want. But my ultimate goal would then be that we have at\n> > least one CI job build and test against such a build system and give it\n> > the \"official blessing\" as an alternative way to build Git.\n> \n> Like, erm, many people :D I spend vast portions of my day inside git. I\n> am not very good at C, though -- and the likelihood of git being\n> completely rewritten in python is quite low -- so I generally do not try\n> very hard to repay that by getting involved in git development (I have\n> some humble patches consisting of a single patch series, which I do feel\n> pretty proud of since it enabled a very useful workflow, but still:\n> ultimately amounts to a one-off event).\n> \n> I do know build systems pretty well though! :) And I'd be happy to\n> collaborate on Meson and help maintain the build system support in the\n> long term, assuming the consensus is that people think it would be a\n> neat idea to add meson support (regardless of whether it serves as a\n> primary or secondary build system).\n\nPeople with different skillsets can repay in different ways, and that's\nnot a bad thing. Not that anybody really has to repay anything. But in\nany case, I would certainly appreciate a second pair of eyes from\nsomebody with expert knowledge on Meson once I have something to show.\n\nI had a deeper look at the CMake build infra that we have and figured\nthat it does make a whole lot of assumptions that autoconf wouldn't\nmake. Those assumptions can of course be removed, and I'd be okay with\ndoing that eventually.\n\nBut for now I'm hacking up an initial iteration of Meson that is good\nenough to build, install and hopefully test Git. The intent here isn't\nquite to preclude us from using CMake as \"official\" build system, but\nrather to make it possible to compare the different build systems with\nactual code, where our choices will be plain Make, autoconf, Meson and\nCMake.\n\nThat should hopefully lead to a more informed discussion.\n\n> Although I'm uninterested in personally working on cmake, as you\n> probably predicted.\n\nFair.\n\nPatrick\n"},{"id":"503455","messageId":"1f002f86-9212-4639-8804-898bc62726e5@gentoo.org","threadId":"62110","inReplyTo":"ZvOTL0cG8qRY8OXe@pks.im","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Eli Schwartz","fromEmail":"eschwartz@gentoo.org","sentAt":"2024-09-25T06:02:34Z","receivedAt":"2024-09-25T06:02:38Z","isPatch":false,"sender":{"key":"eschwartz@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/6551424?v=4"},"body":"On 9/25/24 12:36 AM, Patrick Steinhardt wrote:\n> On Tue, Sep 24, 2024 at 09:59:52AM -0400, Eli Schwartz wrote:\n>> On 9/24/24 8:10 AM, Patrick Steinhardt wrote:\n>> Still I would prefer meson over autotools any day of the week. I'd also\n>> prefer autotools over cmake, mind you.\n> \n> Is that a typo or do you really prefer autotools over CMake? :)\n\n\nPOSIX sh (used by autotools) has a more powerful and capable type system\nthan CMakeLists.txt (this is not a typo either! compare CMake's\n\"semicolon;delimited;string\" type to POSIX sh's \"$@\" type)\n\n\nm4 is less painful to debug than successfully configuring, spending 4\nhours compiling a ginormous project, then failing at the end with (this\nis because of the type system again, since there is no type for\ndependency-was-not-found they smuggle it along as a string value with\nspecial meaning):\nld: cannot find -lCURL-NOTFOUND: No such file or directory\n\n\nIf you enable cmake's test system, but you do it inside a subdir e.g.\ninside tests/CMakeLists.txt, you cannot run \"ctest\" (or make test)\nexcept inside that subdir. ctest will exit 0, and no rules will be\ngenerated to descend into the correct directory instead. This has bitten\nme a *bunch* of times in Gentoo packaging and it always throws me for a\nloop. I don't understand the point of such a design.\n\n\nI have never had autotools refuse point-blank to detect that another\npackage is installed and usable for ***shared linkage*** because my\ndistro automatically removes static libraries when a corresponding\nshared library exists, and\n\nCMake Error at /usr/lib64/cmake/libssh2/Libssh2Config.cmake:92 (message):\n The imported target \"Libssh2::libssh2_static\" references the file\n\n \"/usr/lib64/libssh2.a\"\n\n but this file does not exist. Possible reasons include:\n\n * The file was deleted, renamed, or moved to another location.\n\n * An install or uninstall procedure did not complete successfully.\n\n * The installation package was faulty and contained\n\n \"/usr/lib64/cmake/libssh2/Libssh2Config-relwithdebinfo.cmake\"\n\n but not all the files it references.\n\n\nautotools projects have never harmed me by running the square of my make\n-j$(nproc) count due to recursively running cmake inside of generated\nMakefiles -- perhaps that isn't strictly the fault of CMake but cmake\ndoes very little to discourage it: https://bugs.gentoo.org/921309\n\n\nautotools doesn't have much in the way of built-in tooling for detecting\n\"packages\" instead of \"libraries\" for arbitrary system dependencies. It\nallows you to use pkg-config or code your own (foo-config scripts were\npopular once and in some circles still are). You might think this is a\nnegative, but it's actually a positive compared to cmake, which includes\nbuiltin dependency finders for e.g. zlib that break on a simple version\nupdate because they locate the header file, open it up and use regular\nexpressions to extract a #define for the package version instead of\nasking the preprocessor... a very brittle regex, too:\nhttps://gitlab.kitware.com/cmake/cmake/-/issues/25200\n\n\nautotools projects don't automatically detect your end-to-end\nintegration test's dummy project, integrate its results into your build,\nand install some of your project files twice, once with bad values, but\nonly when you run the project tests (this one was very fun):\nhttps://github.com/nlohmann/json/issues/2907#issuecomment-890580081\n\n\n...\n\n\nI'm probably biased, but some of these failure modes are *weird*. And\nthey basically never require the CMakeLists.txt to do something\nconsidered non-idiomatic in order to trigger the issue.\n\n\n-- \nEli Schwartz\n\n"},{"id":"503456","messageId":"ZvOn_wChzEgXtpMd@pks.im","threadId":"62110","inReplyTo":"1f002f86-9212-4639-8804-898bc62726e5@gentoo.org","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-09-25T06:04:47Z","receivedAt":"2024-09-25T06:04:58Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Wed, Sep 25, 2024 at 02:02:34AM -0400, Eli Schwartz wrote:\n> On 9/25/24 12:36 AM, Patrick Steinhardt wrote:\n> > On Tue, Sep 24, 2024 at 09:59:52AM -0400, Eli Schwartz wrote:\n> >> On 9/24/24 8:10 AM, Patrick Steinhardt wrote:\n> >> Still I would prefer meson over autotools any day of the week. I'd also\n> >> prefer autotools over cmake, mind you.\n> > \n> > Is that a typo or do you really prefer autotools over CMake? :)\n> \n> \n> POSIX sh (used by autotools) has a more powerful and capable type system\n> than CMakeLists.txt (this is not a typo either! compare CMake's\n> \"semicolon;delimited;string\" type to POSIX sh's \"$@\" type)\n> \n> \n> m4 is less painful to debug than successfully configuring, spending 4\n> hours compiling a ginormous project, then failing at the end with (this\n> is because of the type system again, since there is no type for\n> dependency-was-not-found they smuggle it along as a string value with\n> special meaning):\n> ld: cannot find -lCURL-NOTFOUND: No such file or directory\n> \n> \n> If you enable cmake's test system, but you do it inside a subdir e.g.\n> inside tests/CMakeLists.txt, you cannot run \"ctest\" (or make test)\n> except inside that subdir. ctest will exit 0, and no rules will be\n> generated to descend into the correct directory instead. This has bitten\n> me a *bunch* of times in Gentoo packaging and it always throws me for a\n> loop. I don't understand the point of such a design.\n> \n> \n> I have never had autotools refuse point-blank to detect that another\n> package is installed and usable for ***shared linkage*** because my\n> distro automatically removes static libraries when a corresponding\n> shared library exists, and\n> \n> CMake Error at /usr/lib64/cmake/libssh2/Libssh2Config.cmake:92 (message):\n> The imported target \"Libssh2::libssh2_static\" references the file\n> \n> \"/usr/lib64/libssh2.a\"\n> \n> but this file does not exist. Possible reasons include:\n> \n> * The file was deleted, renamed, or moved to another location.\n> \n> * An install or uninstall procedure did not complete successfully.\n> \n> * The installation package was faulty and contained\n> \n> \"/usr/lib64/cmake/libssh2/Libssh2Config-relwithdebinfo.cmake\"\n> \n> but not all the files it references.\n> \n> \n> autotools projects have never harmed me by running the square of my make\n> -j$(nproc) count due to recursively running cmake inside of generated\n> Makefiles -- perhaps that isn't strictly the fault of CMake but cmake\n> does very little to discourage it: https://bugs.gentoo.org/921309\n> \n> \n> autotools doesn't have much in the way of built-in tooling for detecting\n> \"packages\" instead of \"libraries\" for arbitrary system dependencies. It\n> allows you to use pkg-config or code your own (foo-config scripts were\n> popular once and in some circles still are). You might think this is a\n> negative, but it's actually a positive compared to cmake, which includes\n> builtin dependency finders for e.g. zlib that break on a simple version\n> update because they locate the header file, open it up and use regular\n> expressions to extract a #define for the package version instead of\n> asking the preprocessor... a very brittle regex, too:\n> https://gitlab.kitware.com/cmake/cmake/-/issues/25200\n> \n> \n> autotools projects don't automatically detect your end-to-end\n> integration test's dummy project, integrate its results into your build,\n> and install some of your project files twice, once with bad values, but\n> only when you run the project tests (this one was very fun):\n> https://github.com/nlohmann/json/issues/2907#issuecomment-890580081\n> \n> \n> ...\n> \n> \n> I'm probably biased, but some of these failure modes are *weird*. And\n> they basically never require the CMakeLists.txt to do something\n> considered non-idiomatic in order to trigger the issue.\n\nAll of this is very valuable data to make my case for Meson instead of\nCMake. Appreciated, thanks!\n\nPatrick\n"},{"id":"503473","messageId":"5bd2f41c92a00f7799bc543e229b16fa7a473760.camel@mad-scientist.net","threadId":"62110","inReplyTo":"xmqqwmj1t0hp.fsf@gitster.g","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Paul Smith","fromEmail":"paul@mad-scientist.net","sentAt":"2024-09-25T15:33:28Z","receivedAt":"2024-09-25T15:35:07Z","isPatch":false,"sender":{"key":"paul@mad-scientist.net","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"On Tue, 2024-09-24 at 10:39 -0700, Junio C Hamano wrote:\n> Our dependance of heavy use of GNU-ism in our Makefiles makes an\n> argument that make is the common denominator a fairly weak one, so\n> the single one that eventually we use does not have to be \"make\",\n> but it has to be something available widely and easy to learn.\n\nRegardless of what one might imagine :), I am not advocating GNU Make\nas the perfect solution: it certainly has downsides and disadvantages.\n\nBut, it also has benefits that should not be ignored: for example, it's\nhighly portable and it consists of a single binary that can be copied\nanywhere and run from anywhere with no other prerequisites or need for\nany setup or privileges. Also it's extremely flexible since it just\nruns shell scripts. That also makes portability much more \"do it\nyourself\" than other tools of course.\n\nMeson is portable, but that's because it's written in Python: that\nmeans you have to have a Python interpreter already available\n(currently Python 3.7 or better), and the ability to add new modules to\nit. Admittedly this is not a super-high bar in 2024, but it's a non-\ntrivial requirement if you're trying to start from scratch.\n\nThings like cmake provide abstractions that can make building code\nsimple, but it can be surprisingly difficult to get them to perform\nmore advanced tricks like generating source files, linker map files,\netc. It can be done, but it's... not always easy. And it has some\nweird behaviors (for example how cached variables are handled will\ncertainly confuse you at first).\n"},{"id":"503492","messageId":"ZvRhUWcQL2hN4rWU@pks.im","threadId":"62110","inReplyTo":"1f002f86-9212-4639-8804-898bc62726e5@gentoo.org","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-09-25T19:15:36Z","receivedAt":"2024-09-25T19:15:44Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Hey Eli,\n\ndropping the mailing list for a bit: I really want Meson to start become\na thing in Git. I very much feel that the current build infrastructure\nis antiquated and has lots of issues. And while we do have CMake wired\nup somewhat already, it neither is a replacement due to it lacking heaps\nof features/autodetection, nor is it a direction I really want to go.\n\nIt also seems to be the right point in time: Junio hasn't really been a\nfan of converting our build system in the past, but his response to my\nramblings was surprisingly positive. The session I hosted during the Git\ncontributor's summit also seemed positive overall, but I naturally still\nanticipate some bikeshedding.\n\nSo I highly appreciate all the info that you've been posting in this\ncontext, as it helps to solidify my stance quite a bit! Which brings me\nto my ask: would you be willing to do an off-list review before I post\nthings to the Git mailing list? The intent here is to mostly make things\nlook as nice as possible and work out-of-the-box to hopefully sway the\nlist more into favor of Meson.\n\nMy current state is that I've got libgit.a set up while detecting many\nof the important platform-specific bits, the Git executable links just\nfine and I've got unit tests wired up and executing correctly. Still\nmissing is documentation, Perl modules, and fixing some last remaining\nbugs around locales in t0200 and t7816.\n\nAnyway, the current version of this can be found at [1]. Feel free to\nhave a look and provide any feedback, either on the merge request or as\na patch on top. It can be built with `meson setup -Dpython=disabled\n-Dperl=disabled`, enabling these options breaks a bunch more stuff.\n\nThanks!\n\nPatrick\n\n[1]: https://gitlab.com/gitlab-org/git/-/merge_requests/217\n"},{"id":"503493","messageId":"ZvRhwYgWZJb87TZj@pks.im","threadId":"62110","inReplyTo":"ZvRhUWcQL2hN4rWU@pks.im","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-09-25T19:17:21Z","receivedAt":"2024-09-25T19:17:29Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Wed, Sep 25, 2024 at 09:15:36PM +0200, Patrick Steinhardt wrote:\n> Hey Eli,\n> \n> dropping the mailing list for a bit: I really want Meson to start become\n> a thing in Git. I very much feel that the current build infrastructure\n> is antiquated and has lots of issues. And while we do have CMake wired\n> up somewhat already, it neither is a replacement due to it lacking heaps\n> of features/autodetection, nor is it a direction I really want to go.\n\nWell, so much for dropping the mailing list :P Anyway, it's not like\nthere's anything in here that I haven't already said in the context of\nthe Git contributor's summit.\n\nPatrick\n"},{"id":"503502","messageId":"6e3ac135-8357-4d2d-a49b-de7f1ab4da95@gmail.com","threadId":"62110","inReplyTo":"5bd2f41c92a00f7799bc543e229b16fa7a473760.camel@mad-scientist.net","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Eli Schwartz","fromEmail":"eschwartz93@gmail.com","sentAt":"2024-09-26T01:35:05Z","receivedAt":"2024-09-26T01:35:08Z","isPatch":false,"sender":{"key":"eschwartz93@gmail.com","avatar":"https://gravatar.com/avatar/80b459bb75c0edb5e116884705adb9095fbd01cbbf91cb29a9ed23577fff7d34?d=mp&s=160"},"body":"On 9/25/24 11:33 AM, Paul Smith wrote:\n> On Tue, 2024-09-24 at 10:39 -0700, Junio C Hamano wrote:\n>> Our dependance of heavy use of GNU-ism in our Makefiles makes an\n>> argument that make is the common denominator a fairly weak one, so\n>> the single one that eventually we use does not have to be \"make\",\n>> but it has to be something available widely and easy to learn.\n> \n> Regardless of what one might imagine :), I am not advocating GNU Make\n> as the perfect solution: it certainly has downsides and disadvantages.\n\n\n:)\n\nI've read your article about why people should use autoconf!\n\n(By the way: I had a bit of a... chuckle, when I read in your previous\nemail that as the GNU maintainer of Make, you build lots of projects\nwith Make or CMake, but not with GNU autoconf / automake. I assume that\nwas just bad wording?)\n\n\n> But, it also has benefits that should not be ignored: for example, it's\n> highly portable and it consists of a single binary that can be copied\n> anywhere and run from anywhere with no other prerequisites or need for\n> any setup or privileges. Also it's extremely flexible since it just\n> runs shell scripts. That also makes portability much more \"do it\n> yourself\" than other tools of course.\n> \n> Meson is portable, but that's because it's written in Python: that\n> means you have to have a Python interpreter already available\n> (currently Python 3.7 or better), and the ability to add new modules to\n> it. Admittedly this is not a super-high bar in 2024, but it's a non-\n> trivial requirement if you're trying to start from scratch.\n\n\nFWIW: you don't need the ability to add new modules to python, you can\nrun meson by acquiring its sources (tarball or git clone, either one\nworks) and running meson as\n\n$ python3 mesonsources/meson.py ....\n\nNo installation required.\n\nYou can also make a single-file executable using the \"create_zipapp.py\"\npacker that ships in the meson sources. It uses python's ability to\nexecute a .zip archive by expecting the root of the zip file to contain\n\na) the file __main__.py containing the program entrypoint\nb) any additional modules that should be available at runtime\n\nYou do still need python3, sure.\n\nThere are a few different tools available for creating single-file\nexecutables that don't require a python interpreter. What they do is\ncreate a self-extracting executable that includes its own python and\ninternalized support files. Meson uses https://pyinstaller.org to do\nthis in order to create the Windows .msi and macOS .dmg installer\nbundles without requiring the user to install python. I've used it to\ncreate Linux executable installers of meson too -- but I have no strong\nfeelings about linux executable installers existing, so I only bother\ndoing so in order to run tests on the packing process e.g. when I want\nto verify that the Windows installers are ok without actually running\nWindows.\n\nIt's not that hard to build a more or less standalone python that only\ndepends on \"glibc from CentOS 7 or newer\" to use as your base. There's\nan unofficial project that hosts some precompiled versions at\nhttps://gregoryszorc.com/docs/python-build-standalone/main/index.html\n\nSingle-file executables are alive and flourishing. :)\n\nThe same could probably be done for other operating systems and not just\n\"the big 3\", but I lack direct personal experience with deploying\nsoftware to such systems so I can't really say for sure.\n\n\n-- \nEli Schwartz\n\n"},{"id":"503554","messageId":"3a303c6e-35b0-4428-9d23-799b33194330@gmail.com","threadId":"62110","inReplyTo":"ZvOn_wChzEgXtpMd@pks.im","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-09-26T13:55:52Z","receivedAt":"2024-09-26T13:55:55Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Patrick\n\nOn 25/09/2024 07:04, Patrick Steinhardt wrote:\n> On Wed, Sep 25, 2024 at 02:02:34AM -0400, Eli Schwartz wrote:\n>\n>> I'm probably biased, but some of these failure modes are *weird*. And\n>> they basically never require the CMakeLists.txt to do something\n>> considered non-idiomatic in order to trigger the issue.\n> \n> All of this is very valuable data to make my case for Meson instead of\n> CMake. Appreciated, thanks!\n\nOne thing to bear in mind is why our CMakeLists.txt was introduced in \nthe first place [1]. Visual Studio's CMake integration means that so \nlong as git-for-windows is installed building git is simply a case of \nclicking on a button, there is no need to install extra software or \nplugins. I'm not sure the same is true for meson and I don't think we \nwant to end up supporting both.\n\nBest Wishes\n\nPhillip\n\n[1] \nhttps://lore.kernel.org/git/nycvar.QRO.7.76.6.2004251354390.18039@tvgsbejvaqbjf.bet/\n"},{"id":"503555","messageId":"ZvVpcY5Jgp7BzuRu@pks.im","threadId":"62110","inReplyTo":"3a303c6e-35b0-4428-9d23-799b33194330@gmail.com","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-09-26T14:02:32Z","receivedAt":"2024-09-26T14:02:39Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Sep 26, 2024 at 02:55:52PM +0100, Phillip Wood wrote:\n> Hi Patrick\n> \n> On 25/09/2024 07:04, Patrick Steinhardt wrote:\n> > On Wed, Sep 25, 2024 at 02:02:34AM -0400, Eli Schwartz wrote:\n> > \n> > > I'm probably biased, but some of these failure modes are *weird*. And\n> > > they basically never require the CMakeLists.txt to do something\n> > > considered non-idiomatic in order to trigger the issue.\n> > \n> > All of this is very valuable data to make my case for Meson instead of\n> > CMake. Appreciated, thanks!\n> \n> One thing to bear in mind is why our CMakeLists.txt was introduced in the\n> first place [1]. Visual Studio's CMake integration means that so long as\n> git-for-windows is installed building git is simply a case of clicking on a\n> button, there is no need to install extra software or plugins. I'm not sure\n> the same is true for meson and I don't think we want to end up supporting\n> both.\n> \n> Best Wishes\n> \n> Phillip\n> \n> [1] https://lore.kernel.org/git/nycvar.QRO.7.76.6.2004251354390.18039@tvgsbejvaqbjf.bet/\n\nFair enough. The final discussion about which build system to pick is of\ncourse still to be had. Having worked with both CMake and Meson quite a\nbit in the past I'm strongly in favor of Meson myself, and so I will try\nto make a strong case for it. But points like this of course need to be\nconsidered when we have the discussion.\n\nThe nice thing is that we'll then have all serious contenders (that I am\naware of) wired up, even though the level of support will be different\nacross them. But it should allow folks to come to a better understanding\nof what they will be signing up for.\n\nIn any case, I'm now in a state where the Meson-based build works and\ntests just fine, except for t0200, which requires a bit more plumbing to\nset up xgettext infra. Once I'm done with that I'll go off and test with\nboth macOS and Windows to check how the experience is over there. I hope\nto be done with that somewhen next week, at which point I'll send things\nto the mailing list.\n\nPatrick\n"},{"id":"503572","messageId":"71ed5967-0302-42bc-97c7-81886408d688@gentoo.org","threadId":"62110","inReplyTo":"3a303c6e-35b0-4428-9d23-799b33194330@gmail.com","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Eli Schwartz","fromEmail":"eschwartz@gentoo.org","sentAt":"2024-09-26T16:04:27Z","receivedAt":"2024-09-26T16:04:31Z","isPatch":false,"sender":{"key":"eschwartz@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/6551424?v=4"},"body":"On 9/26/24 9:55 AM, Phillip Wood wrote:\n> One thing to bear in mind is why our CMakeLists.txt was introduced in\n> the first place [1]. Visual Studio's CMake integration means that so\n> long as git-for-windows is installed building git is simply a case of\n> clicking on a button, there is no need to install extra software or\n> plugins. I'm not sure the same is true for meson and I don't think we\n> want to end up supporting both.\n\n\nI can't really offer suggestions on what may or may not come\npreinstalled in Visual Studio. That thread does suggest the major\nproblem cmake was trying to solve is:\n\n- having to install the git-for-windows sdk at all (is it still\n necessary? I guess so, because POSIX shell and perl and mingw\n runtimes. Unsure how either meson or cmake could solve this.)\n\n- people who are *unfamiliar with the command line and want a GUI*\n\n\nMeson has a trivially installable VS Code plugin that is supposed to\nhandle setting up the project for you. You can generate either ninja\nprojects or Visual Studio solutions. \"One may need to install a plugin\"\nis hopefully not as big a barrier to entry as \"install a bunch of stuff\nthen go to a shell and run make vcxproj\". Is the criteria truly \"must be\none button click\"?\n\nI'm aware that Visual Studio and VS Code are different IDEs but I know\nnothing really about the former, SEO for distinguishing between the two\nis *atrocious*, they use the same exact plugins marketplace, and I\nfigure using VS Code ought to be easy enough for such users if\nnecessary, anyway.\n\nI think that discussion between Meson / CMake / GNU Make / etc. should\nbe based on technical merit with attention paid to ease of use without\ncoalescing down to \"unfortunately, our choice has been made for us. We\nmust support a *specific* Windows IDE and use whichever build system is\npreinstalled inside that IDE, because it must be a one-button solution\nwith no dependencies\".\n\nStuff like \"how painful is it for a Windows contributor to set up an SDK\nand then also go mess around with Makefile targets and then load the\nresult into their IDE\" is an interesting discussion to have but not\nquite the same as saying \"go to the marketplace and install such and\nsuch plugin\" is an obstacle.\n\n\n-- \nEli Schwartz\n\n"},{"id":"503574","messageId":"xmqqv7yil70d.fsf@gitster.g","threadId":"62110","inReplyTo":"3a303c6e-35b0-4428-9d23-799b33194330@gmail.com","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-26T16:22:26Z","receivedAt":"2024-09-26T16:22:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n> Hi Patrick\n>\n> On 25/09/2024 07:04, Patrick Steinhardt wrote:\n>> On Wed, Sep 25, 2024 at 02:02:34AM -0400, Eli Schwartz wrote:\n>>\n>>> I'm probably biased, but some of these failure modes are *weird*. And\n>>> they basically never require the CMakeLists.txt to do something\n>>> considered non-idiomatic in order to trigger the issue.\n>> All of this is very valuable data to make my case for Meson instead\n>> of\n>> CMake. Appreciated, thanks!\n>\n> One thing to bear in mind is why our CMakeLists.txt was introduced in\n> the first place [1]. Visual Studio's CMake integration means that so\n> long as git-for-windows is installed building git is simply a case of\n> clicking on a button, there is no need to install extra software or\n> plugins. I'm not sure the same is true for meson and I don't think we\n> want to end up supporting both.\n\nIs CMake the _only_ thing that is integrated into Visual Studio?\nAre there other possible candidates that could also be used to build\nfor non-Windows and is usable by this project?\n\n\n\n> Best Wishes\n>\n> Phillip\n>\n> [1]\n> https://lore.kernel.org/git/nycvar.QRO.7.76.6.2004251354390.18039@tvgsbejvaqbjf.bet/\n"},{"id":"503586","messageId":"10debb75cf7d29bc7fb907feae544769f2f2e3be.camel@mad-scientist.net","threadId":"62110","inReplyTo":"6e3ac135-8357-4d2d-a49b-de7f1ab4da95@gmail.com","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Paul Smith","fromEmail":"paul@mad-scientist.net","sentAt":"2024-09-26T19:42:24Z","receivedAt":"2024-09-26T19:44:02Z","isPatch":false,"sender":{"key":"paul@mad-scientist.net","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"On Wed, 2024-09-25 at 21:35 -0400, Eli Schwartz wrote:\n> On 9/25/24 11:33 AM, Paul Smith wrote:\n> > On Tue, 2024-09-24 at 10:39 -0700, Junio C Hamano wrote:\n> > > Our dependance of heavy use of GNU-ism in our Makefiles makes an\n> > > argument that make is the common denominator a fairly weak one,\n> > > so\n> > > the single one that eventually we use does not have to be \"make\",\n> > > but it has to be something available widely and easy to learn.\n> > \n> > Regardless of what one might imagine :), I am not advocating GNU\n> > Make as the perfect solution: it certainly has downsides and\n> > disadvantages.\n> \n> :)\n> \n> I've read your article about why people should use autoconf!\n> \n> (By the way: I had a bit of a... chuckle, when I read in your\n> previous email that as the GNU maintainer of Make, you build lots of\n> projects with Make or CMake, but not with GNU autoconf / automake. I\n> assume that was just bad wording?)\n\nThis is actually part of my $DAYJOB, not as the maintainer of GNU Make.\nIt's not even part of my job there, but I like to have modern tools and\nI hate to mandate certain distributions and distro releases for\neveryone, so I build a complete toolchain including its own sysroot\nthat everyone checks out from a Git repo to build our product.\n\nAt my $DAYJOB we use CMake, actually, so I'm also very familiar with\nit.\n\nBut when I said \"make\" previously I meant to encompass autoconf\nprojects. You're right, it's not really precise to compare make to\ncmake since cmake build makefiles as well. It's more accurate to\ncompare it to autoconf.\n\nSo, I should have said \"autoconf and cmake\" :)\n\nHowever there are also projects that use raw makefiles and no build\ngenerator tools.\n\n\nI certainly didn't mean to imply that requiring Python is a show-\nstopper for Git. There are lots of options depending on needs. But it\ncan't be argued that it's not more work for the builder than using GNU\nMake.\n\nMaybe this is will be deemed not worth worrying about given the\nalternatives, and I wouldn't argue with that. I just raise it so it\ncan be given consideration before a decision is made to (for example)\ndrop support for makefiles.\n"},{"id":"503611","messageId":"b33076f2-ca01-4286-807c-f4b45a00d944@gmail.com","threadId":"62110","inReplyTo":"71ed5967-0302-42bc-97c7-81886408d688@gentoo.org","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-09-27T10:00:39Z","receivedAt":"2024-09-27T10:00:45Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Eli\n\nThanks for this, it's useful to know how meson works with Visual Studio\n\nOn 26/09/2024 17:04, Eli Schwartz wrote:\n> On 9/26/24 9:55 AM, Phillip Wood wrote:\n>> One thing to bear in mind is why our CMakeLists.txt was introduced in\n>> the first place [1]. Visual Studio's CMake integration means that so\n>> long as git-for-windows is installed building git is simply a case of\n>> clicking on a button, there is no need to install extra software or\n>> plugins. I'm not sure the same is true for meson and I don't think we\n>> want to end up supporting both.\n> \n> \n> I can't really offer suggestions on what may or may not come\n> preinstalled in Visual Studio. That thread does suggest the major\n> problem cmake was trying to solve is:\n> \n> - having to install the git-for-windows sdk at all (is it still\n> necessary? I guess so, because POSIX shell and perl and mingw\n> runtimes. Unsure how either meson or cmake could solve this.)\n\nIf you've got git-for-windows installed then it has the POSIX and perl \nbits that are required to run git and the CMake build uses those and \ndownloads any libraries it needs with vcpkg so you don't need the sdk.\n\n> - people who are *unfamiliar with the command line and want a GUI*\n> \n> \n> Meson has a trivially installable VS Code plugin that is supposed to\n> handle setting up the project for you. You can generate either ninja\n> projects or Visual Studio solutions. \"One may need to install a plugin\"\n> is hopefully not as big a barrier to entry as \"install a bunch of stuff\n> then go to a shell and run make vcxproj\". Is the criteria truly \"must be\n> one button click\"?\n\nPersonally I think so long as there is a simple way to build git without \nresorting to the command line that should be fine. It sounds like that's \nthe case with meson.\n\n> [...]\n> Stuff like \"how painful is it for a Windows contributor to set up an SDK\n> and then also go mess around with Makefile targets and then load the\n> result into their IDE\" is an interesting discussion to have but not\n> quite the same as saying \"go to the marketplace and install such and\n> such plugin\" is an obstacle.\n\nAgreed\n\nBest Wishes\n\nPhillip\n"},{"id":"503613","messageId":"5c3b5fcd-37d8-4b8a-bc88-f606f02f346b@gmail.com","threadId":"62110","inReplyTo":"ZvVpcY5Jgp7BzuRu@pks.im","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-09-27T10:10:54Z","receivedAt":"2024-09-27T10:11:00Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Patrick\n\nOn 26/09/2024 15:02, Patrick Steinhardt wrote:\n> On Thu, Sep 26, 2024 at 02:55:52PM +0100, Phillip Wood wrote:\n>> Hi Patrick\n>>\n>> On 25/09/2024 07:04, Patrick Steinhardt wrote:\n>>> On Wed, Sep 25, 2024 at 02:02:34AM -0400, Eli Schwartz wrote:\n>>>\n>>>> I'm probably biased, but some of these failure modes are *weird*. And\n>>>> they basically never require the CMakeLists.txt to do something\n>>>> considered non-idiomatic in order to trigger the issue.\n>>>\n>>> All of this is very valuable data to make my case for Meson instead of\n>>> CMake. Appreciated, thanks!\n>>\n>> One thing to bear in mind is why our CMakeLists.txt was introduced in the\n>> first place [1]. Visual Studio's CMake integration means that so long as\n>> git-for-windows is installed building git is simply a case of clicking on a\n>> button, there is no need to install extra software or plugins. I'm not sure\n>> the same is true for meson and I don't think we want to end up supporting\n>> both.\n>>\n>> Best Wishes\n>>\n>> Phillip\n>>\n>> [1] https://lore.kernel.org/git/nycvar.QRO.7.76.6.2004251354390.18039@tvgsbejvaqbjf.bet/\n> \n> Fair enough. The final discussion about which build system to pick is of\n> course still to be had. Having worked with both CMake and Meson quite a\n> bit in the past I'm strongly in favor of Meson myself, and so I will try\n> to make a strong case for it. But points like this of course need to be\n> considered when we have the discussion.\n\n From what Eli said, we should have a reasonable story for building with \nmeson in Visual Studio\n\n> The nice thing is that we'll then have all serious contenders (that I am\n> aware of) wired up, even though the level of support will be different\n> across them. But it should allow folks to come to a better understanding\n> of what they will be signing up for.\n\nYes, that will be helpful\n\n> In any case, I'm now in a state where the Meson-based build works and\n> tests just fine, except for t0200, which requires a bit more plumbing to\n> set up xgettext infra. Once I'm done with that I'll go off and test with\n> both macOS and Windows to check how the experience is over there. I hope\n> to be done with that somewhen next week, at which point I'll send things\n> to the mailing list.\n\nIt sounds like you're making good progress, I look forward to seeing the \npatches\n\nBest Wishes\n\nPhillip\n"},{"id":"503660","messageId":"39508a38-d98f-3883-3887-971385a3805a@gmx.de","threadId":"62110","inReplyTo":"xmqqv7yil70d.fsf@gitster.g","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2024-09-29T17:56:26Z","receivedAt":"2024-09-29T17:56:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Thu, 26 Sep 2024, Junio C Hamano wrote:\n\n> Phillip Wood writes:\n>\n> > On 25/09/2024 07:04, Patrick Steinhardt wrote:\n> >> On Wed, Sep 25, 2024 at 02:02:34AM -0400, Eli Schwartz wrote:\n> >>\n> >>> I'm probably biased, but some of these failure modes are *weird*.\n> >>> And they basically never require the CMakeLists.txt to do something\n> >>> considered non-idiomatic in order to trigger the issue.\n> >>\n> >> All of this is very valuable data to make my case for Meson instead\n> >> of CMake. Appreciated, thanks!\n> >\n> > One thing to bear in mind is why our CMakeLists.txt was introduced in\n> > the first place [1]. Visual Studio's CMake integration means that so\n> > long as git-for-windows is installed building git is simply a case of\n> > clicking on a button, there is no need to install extra software or\n> > plugins. I'm not sure the same is true for meson and I don't think we\n> > want to end up supporting both.\n>\n> Is CMake the _only_ thing that is integrated into Visual Studio? Are\n> there other possible candidates that could also be used to build for\n> non-Windows and is usable by this project?\n\nThere is one other build system that is highly integrated into Visual\nStudio, and that is MSBuild, using `.vcxproj` files. I do not need three\nguesses to find out what you think about porting Git over to that system.\n\nOther than that, there really is only CMake support:\nhttps://learn.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio\n\nMeson came up as an alternative, so the obvious question is whether it\ncould be used conveniently from within Visual Studio. It takes but one\nlook at https://mesonbuild.com/Using-with-Visual-Studio.html to see that\nno, the instructions ask the developed to use a command-line interface,\nwhich is the opposite of integrating well with an IDE.\n\nIn short: If we're serious that we want to stop treating Windows-based\ndevelopers as if they were unwanted here, we'll need to stick to CMake.\n\nCiao,\nJohannes\n"},{"id":"503661","messageId":"d3900cc3-8a0a-4da1-829b-5bcdd7ebca28@gentoo.org","threadId":"62110","inReplyTo":"39508a38-d98f-3883-3887-971385a3805a@gmx.de","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Eli Schwartz","fromEmail":"eschwartz@gentoo.org","sentAt":"2024-09-29T18:10:24Z","receivedAt":"2024-09-29T18:10:28Z","isPatch":false,"sender":{"key":"eschwartz@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/6551424?v=4"},"body":"On 9/29/24 1:56 PM, Johannes Schindelin wrote:\n> Meson came up as an alternative, so the obvious question is whether it\n> could be used conveniently from within Visual Studio. It takes but one\n> look at https://mesonbuild.com/Using-with-Visual-Studio.html to see that\n> no, the instructions ask the developed to use a command-line interface,\n> which is the opposite of integrating well with an IDE.\n> \n> In short: If we're serious that we want to stop treating Windows-based\n> developers as if they were unwanted here, we'll need to stick to CMake.\n\nHi,\n\nI guess you didn't read the previous comments in this thread? Maybe you\nshould take more than one look. :)\n\n\n-- \nEli Schwartz\n\n"},{"id":"503698","messageId":"a43fa510-9a96-4b92-8107-0c00209d5161@gmail.com","threadId":"62110","inReplyTo":"d3900cc3-8a0a-4da1-829b-5bcdd7ebca28@gentoo.org","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-09-30T08:50:35Z","receivedAt":"2024-09-30T08:50:46Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 29/09/2024 19:10, Eli Schwartz wrote:\n> On 9/29/24 1:56 PM, Johannes Schindelin wrote:\n>> Meson came up as an alternative, so the obvious question is whether it\n>> could be used conveniently from within Visual Studio. It takes but one\n>> look at https://mesonbuild.com/Using-with-Visual-Studio.html to see that\n>> no, the instructions ask the developed to use a command-line interface,\n>> which is the opposite of integrating well with an IDE.\n>>\n>> In short: If we're serious that we want to stop treating Windows-based\n>> developers as if they were unwanted here, we'll need to stick to CMake.\n> \n> Hi,\n> \n> I guess you didn't read the previous comments in this thread? Maybe you\n> should take more than one look. :)\n\nWe cannot expect everyone who wants to build git using meson in Visual \nStudio to read this thread and find the message that mentions installing \na plugin. It is much more likely that they, like Johannes, will find the \ndocumentation on the meson website and conclude they need to run some \ncommands on the commandline. That's a problem with the documentation, \nnot the person reading it. Even if they do find the plugin [1] it is not \nclear that it helps - no where does it say \"this enables you to build \nsoftware with meson\", instead it talks about syntax highlighting, code \nsnippets and linting for meson files.\n\nBest Wishes\n\nPhillip\n\n[1] \nhttps://marketplace.visualstudio.com/items?itemName=mesonbuild.mesonbuild\n\n"},{"id":"503732","messageId":"157253c6-36f8-43ab-ad17-c6c8811bd5a9@gentoo.org","threadId":"62110","inReplyTo":"a43fa510-9a96-4b92-8107-0c00209d5161@gmail.com","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Eli Schwartz","fromEmail":"eschwartz@gentoo.org","sentAt":"2024-09-30T13:57:25Z","receivedAt":"2024-09-30T13:57:33Z","isPatch":false,"sender":{"key":"eschwartz@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/6551424?v=4"},"body":"On 9/30/24 4:50 AM, Phillip Wood wrote:\n> We cannot expect everyone who wants to build git using meson in Visual\n> Studio to read this thread and find the message that mentions installing\n> a plugin. It is much more likely that they, like Johannes, will find the\n> documentation on the meson website and conclude they need to run some\n> commands on the commandline. That's a problem with the documentation,\n> not the person reading it. Even if they do find the plugin [1] it is not\n> clear that it helps - no where does it say \"this enables you to build\n> software with meson\", instead it talks about syntax highlighting, code\n> snippets and linting for meson files.\n\n\nSure. And I'm happy to (help) improve the documentation. I've already\npushed a fix to the page Johannes linked, since it was many years out of\ndate (???) and didn't reflect the fact that meson will automatically\ndetect the Visual Studio toolset for you.\n\n(Note that since meson will \"automatically do the right thing\" here,\nthat means it is practical for a plugin to run meson under the hood for\nyou... much like how cmake plugins handle things.)\n\n\nAs far as reading this thread goes, though, I assume that in such a\nfuture, people who want to build git using meson in Visual Studio would\nbe optimally served by a slight reorganization to ./INSTALL to provide\nguidance on where to find meson and what plugin to use, which provides\nan additional entrypoint for clarification. :)\n\n\n-- \nEli Schwartz\n\n"},{"id":"503736","messageId":"3b12cfe9-0291-87ba-6324-232a86ed716a@gmx.de","threadId":"62110","inReplyTo":"a43fa510-9a96-4b92-8107-0c00209d5161@gmail.com","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2024-09-30T16:05:35Z","receivedAt":"2024-09-30T16:06:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Phillip,\n\nOn Mon, 30 Sep 2024, Phillip Wood wrote:\n\n> On 29/09/2024 19:10, Eli Schwartz wrote:\n> > On 9/29/24 1:56 PM, Johannes Schindelin wrote:\n> > > Meson came up as an alternative, so the obvious question is whether it\n> > > could be used conveniently from within Visual Studio. It takes but one\n> > > look at https://mesonbuild.com/Using-with-Visual-Studio.html to see that\n> > > no, the instructions ask the developed to use a command-line interface,\n> > > which is the opposite of integrating well with an IDE.\n> > >\n> > > In short: If we're serious that we want to stop treating Windows-based\n> > > developers as if they were unwanted here, we'll need to stick to CMake.\n> >\n> > I guess you didn't read the previous comments in this thread? Maybe you\n> > should take more than one look. :)\n>\n> We cannot expect everyone who wants to build git using meson in Visual Studio\n> to read this thread and find the message that mentions installing a plugin. It\n> is much more likely that they, like Johannes, will find the documentation on\n> the meson website and conclude they need to run some commands on the\n> commandline. That's a problem with the documentation, not the person reading\n> it. Even if they do find the plugin [1] it is not clear that it helps - no\n> where does it say \"this enables you to build software with meson\", instead it\n> talks about syntax highlighting, code snippets and linting for meson files.\n\nI had actually read it. Not wanting to be xkcd 386, I had decided to\nrefrain from replying. But it would appear that I have to.\n\n> [1] https://marketplace.visualstudio.com/items?itemName=mesonbuild.mesonbuild\n\nThank you for providing an actual link, it was missing in this thread\n(handwaving is not really good enough, I would say).\n\nOn that page, we see a serious flaw in the argument made in\nhttps://lore.kernel.org/git/71ed5967-0302-42bc-97c7-81886408d688@gentoo.org/:\n\n\tVisual Studio Code>Programming Languages>Meson\n\n\t[...]\n\n\tMeson for Visual Studio Code\n\nNow, I am the first to admit that it is confusing that there is Visual\nStudio Code and then there is Visual Studio, and those two products share\nmostly the \"Visual Studio\" in their name, but little else.\n\nMost notably, you cannot install VS Code Extensions into Visual Studio,\nand vice versa Visual Studio extensions cannot be installed into VS Code.\nSee https://www.freecodecamp.org/news/visual-studio-vs-visual-studio-code/\nor https://dev.to/hadil/the-difference-between-visual-studio-vs-visual-studio-code-35oh\nfor more detailed explanations.\n\nAnd when you navigate on that Marketplace to the Visual Studio extensions\n(sans \"Code\"), you will find that, frustratingly,\nhttps://marketplace.visualstudio.com/search?term=meson&target=VS comes up\nempty:\n\n\tYour search for 'meson' didn't match any extensions\n\nIn other words: Visual Studio, _the_ most prevalent IDE for Windows-based\nC/C++ developers, has no Meson support worth talking about. None.\n\nNow, how about instead suggesting VS Code to direct Windows-based\ndevelopers who are eager to contribute to Git? Alas, VS Code does not come\nwith a C/C++ compiler. Not even a canonical extension to compile C. Even\nif there were, the user experience of having to scour around for plugins\nand 3rd-party software to install, and _then_ somehow getting the needed\nlibraries like libcurl into that setup, _just_ to build Git (and we are\nnot even yet talking about running tests from Git's test suite that do not\neagerly lend themselves to be run from common test frameworks that would\nbe supported by VS Code _extensions_) is about 100x worse than telling\ncontributors to simply open their git.git checkout in Visual Studio and\nlet CMake do its thing.\n\nYes, I made up that \"100x\" from thin air, but it's easy to imagine that\nsome (most?) developers would contend that this is a few orders of\nmagnitude too generous.\n\nPersonally, I have to admit that I find very, very little consolation in\nthe suggestion that these days, Meson will \"automatically do the right\nthing\", without requiring to be run in a VS Developer Prompt:\n_These commands still have to be run in a Command Prompt_, i.e. completely\noutside of Visual Studio, in a text-based terminal that Windows-based\ndevelopers will find off-putting to the point of rolling their eyes at the\nsuggestion.\n\nIn summary: From my perspective, these quite serious flaws put quite a\nhuge dent into the credibility of these arguments pro Meson (and contra\nCMake). Forcing Windows-based developers away from CMake and toward Meson\nwould definitely make the developer experience substantially worse. To be\nhonest, I hoped that we would make the experience better. Certainly not\nworse.\n\nCiao,\nJohannes\n"},{"id":"503740","messageId":"xmqqr0919k8p.fsf@gitster.g","threadId":"62110","inReplyTo":"157253c6-36f8-43ab-ad17-c6c8811bd5a9@gentoo.org","subject":"Re: ./configure fails to link test program due to missing dependencies","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-30T16:31:02Z","receivedAt":"2024-09-30T16:31:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eli Schwartz writes:\n\n> Sure. And I'm happy to (help) improve the documentation. I've already\n> pushed a fix to the page Johannes linked, since it was many years out of\n> date (???) and didn't reflect the fact that meson will automatically\n> detect the Visual Studio toolset for you.\n>\n> (Note that since meson will \"automatically do the right thing\" here,\n> that means it is practical for a plugin to run meson under the hood for\n> you... much like how cmake plugins handle things.)\n>\n>\n> As far as reading this thread goes, though, I assume that in such a\n> future, people who want to build git using meson in Visual Studio would\n> be optimally served by a slight reorganization to ./INSTALL to provide\n> guidance on where to find meson and what plugin to use, which provides\n> an additional entrypoint for clarification. :)\n\nYup, whenever a procedure changes, documentation to guide folks\nalong the procedure need to change. Otherwise they will be lost.\n\nAnd it is very good that we see people are improving the candidates\nbeing offered that way, not just enumerating how it is superior to\nthe status quo (in their opinion) once adopted, but making sure it\nwould not inconvenience or alienate existing users who are used to\nthe way proposed for deprecation.\n\n\n"}]}