search

rrthomas / plptools

Tools for connection to EPOC devices
GNU General Public License v2.0
19 stars 8 forks source link

Install on MacOS #11

Closed mikeydelamonde closed 8 months ago

mikeydelamonde commented 8 months ago

Hi everyone. I thought I would test out the new build process on a Mac at work which is fresh and hasn't had a build before. It's not working as it used to (it worked before!)

  1. installed git by running xcode-select --install
  2. looked in the build file (this isn't too user friendly, could this go in the instructions?) and ran brew install coreutils readline automake gettext macfuse
  3. ran ./bootstrap --skip-po
  4. Got an error: 
    bootstrap:   error: One of these is required:
bootstrap:                 libtoolize glibtoolize
bootstrap:   error: Please install GNU Libtool, or 'export LIBTOOLIZE=/path/to/libtoolize'.

    so I ran brew install libtool

  5. ran ./bootstrap --skip-po again and got error: 
    bootstrap:   error: Prerequisite 'gpg' not found. Please install it, or
bootstrap:          'export GPG=/path/to/gpg'.
bootstrap:   error: Program    Min_version Homepage                            
bootstrap:          -----------------------------------------------------------
bootstrap:          git        1.5.5       https://git-scm.com                 
bootstrap:          gpg        1.4.11      https://www.gnupg.org               
bootstrap:          perl       5.5         https://perl.com                    
bootstrap:          tar        -           https://www.gnu.org/s/tar           
bootstrap:          autoconf   2.71        https://www.gnu.org/s/autoconf      
bootstrap:          automake   -           https://www.gnu.org/s/automake      
bootstrap:          autopoint  0.19.6      https://www.gnu.org/s/gettext       
bootstrap:          -----------------------------------------------------------
  6. So I then went and installed https://gpgtools.org/ (I am pretty sure i've never installed this on my mac at home)
  7. ran ./bootstrap --skip-po again and got 
    bootstrap: warning: Consider installing git-merge-changelog from gnulib.
bootstrap: running: autopoint --force
/Library/Developer/CommandLineTools/usr/bin/gm4: unrecognized option `--gnu'
Try `/Library/Developer/CommandLineTools/usr/bin/gm4 --help' for more information.
autom4te: error: /usr/bin/gm4 failed with exit status: 1
Copying file ABOUT-NLS
Copying file build-aux/config.rpath
Copying file m4/codeset.m4
Copying file m4/extern-inline.m4
Copying file m4/fcntl-o.m4
Copying file m4/gettext.m4
Copying file m4/iconv.m4
Copying file m4/intdiv0.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intlmacosx.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-pri.m4
Copying file m4/lcmessage.m4
Copying file m4/lib-ld.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/progtest.m4
Copying file m4/threadlib.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
Copying file po/Rules-quot
Copying file po/boldquot.sed
Copying file po/en@boldquot.header
Copying file po/en@quot.header
Copying file po/insert-header.sin
Copying file po/quot.sed
Copying file po/remove-potcdate.sin
bootstrap: running: /opt/homebrew/bin/glibtoolize --quiet
bootstrap: running: git clone --shallow-since=2024-02-26 'git://git.sv.gnu.org/gnulib.git' 'gnulib'
Cloning into 'gnulib'...
remote: Counting objects: 11364, done.
remote: Compressing objects: 100% (10153/10153), done.
remote: Total 11364 (delta 5677), reused 2575 (delta 1190)
Receiving objects: 100% (11364/11364), 10.32 MiB | 4.67 MiB/s, done.
Resolving deltas: 100% (5677/5677), done.
bootstrap: running: git submodule init -- gnulib
Submodule 'gnulib' (git://git.sv.gnu.org/gnulib.git) registered for path 'gnulib'
bootstrap: running: git submodule update -- gnulib
remote: Counting objects: 271341, done.
remote: Compressing objects: 100% (34752/34752), done.
remote: Total 271341 (delta 244297), reused 263128 (delta 236512)
Receiving objects: 100% (271341/271341), 61.41 MiB | 15.22 MiB/s, done.
Resolving deltas: 100% (244297/244297), completed with 6214 local objects.
From git://git.sv.gnu.org/gnulib
* branch                  a235aed6a25e52eb99e1ef71c070a258dd88a3e9 -> FETCH_HEAD
Submodule path 'gnulib': checked out 'a235aed6a25e52eb99e1ef71c070a258dd88a3e9'
bootstrap: running: git submodule init -- gl-mod/bootstrap
Submodule 'gl-mod/bootstrap' (https://github.com/gnulib-modules/bootstrap.git) registered for path 'gl-mod/bootstrap'
bootstrap: running: git submodule update -- gl-mod/bootstrap
Cloning into '/Users/michael.johnson/Developer/plptools/gl-mod/bootstrap'...
Submodule path 'gl-mod/bootstrap': checked out '6866c3d5d81a1456a1885d601e6ad0da180f6bd4'
bootstrap: running: gnulib/gnulib-tool --no-libtool --no-changelog --aux-dir=build-aux --m4-base=m4 --local-dir=gl --local-dir=gl-mod/bootstrap --source-base=libgnu --symlink --import bootstrap hostent...
gnulib/gnulib-tool: 'join' program is buggy. Consider installing GNU coreutils.
  8. This doesn't have any obvious errors, but ./configure doesn't work
rrthomas commented 8 months ago

There's an obvious error above: you need to install coreutils and add it to your PATH. I suggest following what the GitHub CI config does (.github/workflows/c-cpp.yml) as that starts from a fresh system (with brew installed, admittedly, but only default packages, I believe).

mikeydelamonde commented 8 months ago

Hmm OK, I did install coreutils as part of the big brew install in my step 2 above, by reading that GitHub-CI file, but will see if the path is the problem when I go back to the office!

rrthomas commented 8 months ago

The problem is most likely not adding coreutils's utilities to PATH under their default names (without g prefix).

kapfab commented 8 months ago

Yes, coreutils and m4 are also needed but by default the associated commands (which are already bundled with macOS but in a different version) are prefixed with a 'g' (gjoin, gm4, etc.). To allow these command to override the default ones, you need to add specific directories to your path:

PATH="$(brew --prefix coreutils)/libexec/gnubin:$(brew --prefix m4)/bin:$PATH"
mikeydelamonde commented 8 months ago

Awesome, the PATH update allowed it to continue. The next error is when running ./configure

./configure: line 33009: syntax error near unexpected token `FUSE,'

./configure: line 33009: `PKG_CHECK_MODULES(FUSE, fuse >= 2.6, enable_fuse=yes, enable_fuse=no)'

The install of macfuse with homebrew was successful.

(I will compile these instructions into a README pull request if helpful, once it's building again!)

On Wed, 28 Feb 2024 at 20:57, Capt.Fab. @.***> wrote:

Yes, coreutils and m4 are also needed but by default the associated commands (which are already bundled with macOS but in a different version) are prefixed with a 'g' (gjoin, gm4, etc.). To allow these command to override the default ones, you need to add specific directories to your path:

PATH="$(brew --prefix coreutils)/libexec/gnubin:$(brew --prefix m4)/bin:$PATH"

— Reply to this email directly, view it on GitHub https://github.com/rrthomas/plptools/issues/11#issuecomment-1969904227, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI5UN5SEPPJJ527PSLG6ITYV6KZZAVCNFSM6AAAAABD6PRYIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRZHEYDIMRSG4 . You are receiving this because you authored the thread.Message ID: @.***>

kapfab commented 8 months ago

Looks like you don't have pkg-config installed or in your PATH.

rrthomas commented 8 months ago

I have added a check for pkg-config to bootstrap.conf, and added it (redundantly) to the list of packages to install in the GitHub workflow.

As I said above, I won't be restoring macOS-specific instructions to README, because I don't want to support them.

(Quick bit of perspective: I use Ubuntu. I go to great lengths to try to make the packages I maintain run on any POSIX-compatible OS (and in some cases, Windows). I don't offer support as a rule for users of any operating system, because I don't know much even about other GNU/Linux distros, and I would rather delegate that work to expert packagers. My expertise is in the packages.)

rrthomas commented 8 months ago

Don't update yet, my check for pkg-config is buggy, and I may not be able to fix it immediately! Sorry!

UPDATE: it looks like a bug in bootstrap, so I've removed the check for now. It seems it can't cope with a hyphenated program name.

mikeydelamonde commented 8 months ago

I see, understood. I hope these messages aren't too annoying then, but would be wonderful if the build just worked on the mac, as long as it doesn't go too bespoke!

Anyhow, I ran: brew install pkg-config, and it wasn't installed, but then re-running ./configure complains on the same lines:

./configure: line 33009: syntax error near unexpected token `FUSE,'

./configure: line 33009: `PKG_CHECK_MODULES(FUSE, fuse >= 2.6, enable_fuse=yes, enable_fuse=no)'

just running pkg-config on the command line works so I think it's in the PATH to be found.

On Thu, 29 Feb 2024 at 11:22, Reuben Thomas @.***> wrote:

I have added a check for pkg-config to bootstrap.conf, and added it (redundantly) to the list of packages to install in the GitHub workflow.

As I said above, I won't be restoring macOS-specific instructions to README, because I don't want to support them.

(Quick bit of perspective: I use Ubuntu. I go to great lengths to try to make the packages I maintain run on any POSIX-compatible OS (and in some cases, Windows). I don't offer support as a rule for users of any operating system, because I don't know much even about other GNU/Linux distros, and I would rather delegate that work to expert packagers. My expertise is in the packages.)

— Reply to this email directly, view it on GitHub https://github.com/rrthomas/plptools/issues/11#issuecomment-1970911602, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI5UNYFLFTSPMIUJOVI7B3YV4HN5AVCNFSM6AAAAABD6PRYIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZQHEYTCNRQGI . You are receiving this because you authored the thread.Message ID: @.***>

rrthomas commented 8 months ago

I see, understood. I hope these messages aren't too annoying then, but would be wonderful if the build just worked on the mac, as long as it doesn't go too bespoke!

No, that's fine, you've both been very helpful. The build expects a compliant POSIX system, with a few extras (mainly GNU m4) that are beyond my control, so macOS will for the foreseeable future require some configuration. Maybe brew has or will gain a setup for POSIX compliance; that would be the obvious way to fix what Apple clearly aren't interested in fixing.

Having installed pkg-config you'll need to rerun bootstrap.

rrthomas commented 8 months ago

(Of course once @kapfab has packaged plptools for brew, you won't need to build it any more.)

mikeydelamonde commented 8 months ago

Great - did that step and now it works! If you wanted to add a redundant brew install pkg-config then it wouldn't go amiss! Also, I know you don't want mac-only steps but the PATH="$(brew --prefix coreutils)/libexec/gnubin:$(brew --prefix m4)/bin:$PATH" you gave me did the trick and the line in the Github-CI file isn't the same and would have helped as that was the only missing thing once all the packages and PGP were installed.

Cheers again, Mike

On Thu, 29 Feb 2024 at 11:37, Reuben Thomas @.***> wrote:

I see, understood. I hope these messages aren't too annoying then, but would be wonderful if the build just worked on the mac, as long as it doesn't go too bespoke!

No, that's fine, you've both been very helpful. The build expects a compliant POSIX system, with a few extras (mainly GNU m4) that are beyond my control, so macOS will for the foreseeable future require some configuration. Maybe brew has or will gain a setup for POSIX compliance; that would be the obvious way to fix what Apple clearly aren't interested in fixing.

Having installed pkg-config you'll need to rerun bootstrap.

— Reply to this email directly, view it on GitHub https://github.com/rrthomas/plptools/issues/11#issuecomment-1970950658, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI5UN47PSMVVKV6Q2YYKJLYV4JJJAVCNFSM6AAAAABD6PRYIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZQHE2TANRVHA . You are receiving this because you authored the thread.Message ID: @.***>

-- Michael Johnson +44 (0)7977 555 010

rrthomas commented 8 months ago

Great - did that step and now it works!

Good stuff!

If you wanted to add a redundant brew install pkg-config then it wouldn't go amiss!

It's already there.

Also, I know you don't want mac-only steps but the PATH="$(brew --prefix coreutils)/libexec/gnubin:$(brew --prefix m4)/bin:$PATH" you gave me did the trick and the line in the Github-CI file isn't the same and would have helped as that was the only missing thing once all the packages and PGP were installed.

The only thing I can see that's different in the GitHub CI file is that it assumes the prefixes are fixed. I don't think there was anything missing? Are you saying that GPG needs to be installed and wasn't?

In any case, I've updated the GitHub CI file to use brew --prefix rather than assuming the paths.

kapfab commented 8 months ago

In any case, I've updated the GitHub CI file to use brew --prefix rather than assuming the paths.

Yes, it should be done like that because brew uses a different path for x86 and Apple Silicon.

rrthomas commented 8 months ago

If you wanted to add a redundant brew install pkg-config then it wouldn't go amiss!

It's already there. The only thing I can see that's different in the GitHub CI file is that it assumes the prefixes are fixed. I don't think there was anything missing? Are you saying that GPG needs to be installed and wasn't?

In any case, I've updated the GitHub CI file to use brew --prefix rather than assuming the paths.

@mikeydelamonde please can you confirm whether you meant GPG (package gnupg) rather than pkg-config, which is already (redundantly) listed in the brew install command?

rrthomas commented 8 months ago

The bootstrap bug has been fixed, so I've now added pkg-config as a dependency in bootstrap.conf.

kapfab commented 8 months ago

Bad news, it looks like we can’t make a Brew package for plptools because the GitHub repo is not notable enough (<30 forks, <30 watchers and <75 stars). This repo has been around for 8 years or more, so I don’t see macOS support bringing more forks, watchers or stars in the foreseeable future.

I could create a dedicated tap (external Brew source) but I don’t want to go this way because of the reduced discoverability it implies.

Apart from that, I also get an error because m4 is already provided by macOS, but that could probably be ignored by the review team with a little explanation.

Incidentally, the GitHub license should be either GPL-2.0-only or GPL-2.0-or-later to conform to SPDX (currently GPL-2.0).

kapfab commented 8 months ago

@rrthomas, is your macOS CI workflow already operational?

Yes, see https://github.com/rrthomas/plptools/actions

mikeydelamonde commented 8 months ago

I'm not too sure - I'll have to find another fresh mac victim to try it!

On Mon, 4 Mar 2024 at 11:57, Reuben Thomas @.***> wrote:

If you wanted to add a redundant brew install pkg-config then it wouldn't go amiss!

It's already there. The only thing I can see that's different in the GitHub CI file is that it assumes the prefixes are fixed. I don't think there was anything missing? Are you saying that GPG needs to be installed and wasn't?

In any case, I've updated the GitHub CI file to use brew --prefix rather than assuming the paths.

@mikeydelamonde https://github.com/mikeydelamonde please can you confirm whether you meant GPG (package gnupg) rather than pkg-config, which is already (redundantly) listed in the brew install command?

— Reply to this email directly, view it on GitHub https://github.com/rrthomas/plptools/issues/11#issuecomment-1976417015, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI5UN24WK4J5YTIBDTHGXLYWRORDAVCNFSM6AAAAABD6PRYIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZWGQYTOMBRGU . You are receiving this because you were mentioned.Message ID: @.***>

-- Michael Johnson +44 (0)7977 555 010

rrthomas commented 8 months ago

Bad news, it looks like we can’t make a Brew package for plptools because the GitHub repo is not notable enough (<30 forks, <30 watchers and <75 stars). This repo has been around for 8 years or more, so I don’t see macOS support bringing more forks, watchers or stars in the foreseeable future.

Exactly, I don't think this is a problem: the package is mature (so unlikely to trouble brew with maintenance requirements) and notable (it's widely distributed, being currently packaged in Debian, Fedora, NetBSD etc.). I think a few citations should convince the brew maintainers.

Apart from that, I also get an error because m4 is already provided by macOS, but that could probably be ignored by the review team with a little explanation.

I'm sure that shouldn't be a problem, since brew provides GNU m4 itself, for good reason.

Incidentally, the GitHub license should be either GPL-2.0-only or GPL-2.0-or-later to conform to SPDX (currently GPL-2.0).

I can't work out how to change this. GitHub seems to read the COPYING file, but of course that is just the text of the GPL (and it is installed by GNU autotools, so I don't want to change it). Even so, I tried to find out how to change the license on GitHub. According to the instructions you can only add a license to a repo, but nothing there explains how to add an "-or-later" license, and when I try adding a license, all I can do is pick a version of the GPL, not specify ("only this" or "and later"). I'm probably missing something? In any case, I don't see why GitHub metadata should be necessary for SPDX, which as I understand it relies on a file inside the repo. I hope you'll excuse my having limited patience for GitHub's proprietary features.

A little more searching suggested that maybe the name of the file matters (I found GPL-3.0-or-later.txt in another repo), but of course I'm not changing the file from the GNU Coding Standards-mandated form just to please a proprietary hosting service.

If someone wanted to provide SPDX metadata for the project, I would happily accept that.

rrthomas commented 8 months ago

For example, another mature package I maintain is in brew.

It has a laughably small number of stars and forks, unsurprisingly, since I took it over many years after it was so widely packaged that everyone expected to find it in their distros (so for example it was already in brew when I started my github fork; even the upstream only has 13 forks, 13 stars and 2 watchers).

kapfab commented 8 months ago

It seems they added these thresholds some years ago because they ended with a lot of unmaintained packages.

I’ll try to push the formula with some context and we’ll see what happens. I think your whole GitHub account should be enough to convince the Brew reviewers that you are a committed maintainer and that plptools is not the brand new ephemeral hype app of the week…

Sorry for the misunderstanding regarding the SPDX license: it doesn’t have to be changed on the GitHub side, it’s an attribute within the Brew formula (whose default value is gathered from the GitHub repo). I just need to know if the correct license is GPL-2.0-only or GPL-2.0-or-later. Do you know?

kapfab commented 8 months ago

I was expecting to find the bootstrap script in the plptools-1.0.20.tar.gz, but it already has the configure script ready to go. Is it how it’s intended to work for releases or should I still run bootstrap if configure is missing?

rrthomas commented 8 months ago

It seems they added these thresholds some years ago because they ended with a lot of unmaintained packages.

This is of course fair enough. But is the "unmaintained" bit worrying about brew maintainers or upstream maintainers? An active upstream maintainer is not that handy if the brew package is not being updated; on the other hand, an active brew maintainer can potentially fix serious upstream bugs (at least, Debian do this for their packages), or, worst case, ask for it to be removed.

I’ll try to push the formula with some context and we’ll see what happens. I think your whole GitHub account should be enough to convince the Brew reviewers that you are a committed maintainer and that plptools is not the brand new ephemeral hype app of the week…

:)

Sorry for the misunderstanding regarding the SPDX license: it doesn’t have to be changed on the GitHub side, it’s an attribute within the Brew formula (whose default value is gathered from the GitHub repo). I just need to know if the correct license is GPL-2.0-only or GPL-2.0-or-later. Do you know?

Sorry, this information is currently buried in the copyright headers of the source; I shall also surface it in the README. It is GPL-2.0-or-later.

rrthomas commented 8 months ago

I was expecting to find the bootstrap script in the plptools-1.0.20.tar.gz, but it already has the configure script ready to go. Is it how it’s intended to work for releases or should I still run bootstrap if configure is missing?

Exactly, source releases start with ./configure. (Again, this is standard for GNU packages and others like plptools that use GNU autotools, but I realise that it's increasingly an anachronistic oddity to those who aren't stuck maintaining a bunch of multi-decade-old code!)

kapfab commented 8 months ago

But is the "unmaintained" bit worrying about brew maintainers or upstream maintainers?

Both, I guess, but rather for upstream maintainers. Brew contributors can take the responsibility to fix issues with formulas they merge into the homebrew-core but not with the associated upstream projects.

rrthomas commented 8 months ago

Well, plptools will hopefully be good for another few years without major attention with my latest round of updates. The application end is a dead system that isn't going to change, POSIX is stable, FUSE is stable, and I've done my best to make the code please C++ and its compilers circa now.

kapfab commented 8 months ago

I was expecting to find the bootstrap script in the plptools-1.0.20.tar.gz, but it already has the configure script ready to go. Is it how it’s intended to work for releases or should I still run bootstrap if configure is missing?

Exactly, source releases start with ./configure. (Again, this is standard for GNU packages and others like plptools that use GNU autotools, but I realise that it's increasingly an anachronistic oddity to those who aren't stuck maintaining a bunch of multi-decade-old code!)

Both cases are now handled by my Brew formula, bootstrap and its dependencies will be used when building from HEAD but not for releases.

I see in the bootstrap code that MacPorts/Homebrew ‘g’ prefixed binary names are already handled:

func_find_tool M4 gm4 gnum4 m4
func_find_tool LIBTOOLIZE libtoolize glibtoolize

Do you think it could be possible to put gm4 before m4 in order to avoid the macOS specific PATH override?

Also, I would have expected to see the following line somewhere:

func_find_tool JOIN join gjoin

but join does not seem to have been handled in the same way as other commands. Do you know why and if this could be changed too?

rrthomas commented 8 months ago

Both cases are now handled by my Brew formula, bootstrap and its dependencies will be used when building from HEAD but not for releases.

Great stuff!

I see in the bootstrap code that MacPorts/Homebrew ‘g’ prefixed binary names are already handled:

Well noticed!

Do you think it could be possible to put gm4 before m4 in order to avoid the macOS specific PATH override?

I'll raise an issue upstream, that would be good.

but join does not seem to have been handled in the same way as other commands. Do you know why and if this could be changed too?

This will be because no-one knew macOS join was broken until this year, and I am not using gnulib's own bootstrap but a third-party drop-in replacement, so I'll raise an issue for that too.

Excellent work, thanks!

kapfab commented 8 months ago

If both changes could be done, that would be great!

I could get rid of the PATH overrides and, as Brew seems to automatically add the CPPFLAGS/LDFLAGS for libs set as dependencies, the formula would only need two clean lists of dependencies.

kapfab commented 8 months ago

@rrthomas, just seen that Apple ships both m4 and gm4 commands with macOS (same duplicated binary)! Would still be good for gjoin, which doesn’t exist (yet?) in macOS.

rrthomas commented 8 months ago

@rrthomas, just seen that Apple ships both m4 and gm4 commands with macOS (same duplicated binary)!

FML, but thanks for the heads up before I posted a pointless issue.

Would still be good for gjoin, which doesn’t exist (yet?) in macOS.

I have asked for this.

kapfab commented 8 months ago

Building from source seems to work fine now without prepending GNU M4 to the PATH, I don’t get the unrecognized option '--gnu’ error anymore. Did you make any related change in the last few days?

rrthomas commented 8 months ago

Not that I'm aware of. I would double check which version of M4 is actually being used.

kapfab commented 8 months ago

Apparently the Apple one, the GNU M4 directory is nowhere in the PATH, which m4 and which gm4 both point to /usr/bin.

rrthomas commented 8 months ago

Hmm. m4 1.4.12 is required by some of my projects, I think because that's the oldest version supporting --gnu. I thought macOS shipped 1.4.6. I cannot now find why --gnu was required or what uses it! If in fact the version supplied with macOS works fine, great.

rrthomas commented 8 months ago

For join/gjoin, the bootstrap maintainer rightly points out that's a problem for gnulib, not bootstrap, which doesn't use join itself, so I've asked about this on the gnulib mailing list.

kapfab commented 8 months ago

Hmm. m4 1.4.12 is required by some of my projects, I think because that's the oldest version supporting --gnu. I thought macOS shipped 1.4.6. I cannot now find why --gnu was required or what uses it! If in fact the version supplied with macOS works fine, great.

Yes, macOS does comes with GNU M4 1.4.6.

And when I built manually, I still got the --gnu error.

So I had a quick look at the Brew source code and discovered it does some magic when building formulas, in particular:

So this mean that if we can sort out the gjoin issue, the Brew formula will be clean and simple without any specific PATH override!

rrthomas commented 8 months ago

OK. Looks like the gnulib maintainers prefer users to set their PATH rather than check for other names, but I've done my best to argue for it, so we'll see.

kapfab commented 8 months ago

That would not be consistent with what they already do with some commands…

find_tool SHA1SUM sha1sum gsha1sum shasum sha1
find_tool LIBTOOLIZE glibtoolize libtoolize
find_tool XARGS gxargs xargs
rrthomas commented 8 months ago

That would not be consistent with what they already do with some commands…

find_tool SHA1SUM sha1sum gsha1sum shasum sha1
find_tool LIBTOOLIZE glibtoolize libtoolize
find_tool XARGS gxargs xargs

This is in bootstrap, which is not part of gnulib in this case (I'm using a 3rd party bootstrap).

kapfab commented 8 months ago

I found those ones in scripts within the gnulib folder (I found those ones in scripts within the gnulib folder (gnulib/top/bootstrap-funclib.sh, gnulib/build-aux/bootstrap, gnulib/build-aux/gnu-web-doc-update).

rrthomas commented 8 months ago

I found those ones in scripts within the gnulib folder (I found those ones in scripts within the gnulib folder (gnulib/top/bootstrap-funclib.sh, gnulib/build-aux/bootstrap, gnulib/build-aux/gnu-web-doc-update).

Good point, I'll raise that.

rrthomas commented 8 months ago

OK, pro-user sentiment carried the day and there's now gjoin detection in gnulib. I've updated plptools to use the latest gnulib. I updated GitHub CI not to add the coreutils bin directory to PATH, and the macOS build still goes through. If you confirm that it works for you when building for brew, I can make another release and close this issue!

kapfab commented 8 months ago

That’s great, thanks! I confirm the Brew formula now works without any PATH override.

rrthomas commented 8 months ago

Great, closing. I'll make a new release with the latest update.