Also, Apple has super security around /usr/bin/make. If I copy /opt/homebrew/bin//gmake to /opt/homebrew/bin//make and put it ahead of /usr/bin/make in the path
$ which -a make /opt/homebrew/bin//make /usr/bin/make ~/Src/petsc (barry/2023-05-14/add-fortran-petsccheck=) arch-add-fortran-petsccheck $ make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. It uses the /usr/bin/make And I cannot delete /usr/bin/make $ sudo rm -rf /usr/bin/make rm: /usr/bin/make: Operation not permitted So make at the command line always uses the old one provided by Apple; it does not use the /opt/homebrew/bin/make one But if I copy /opt/homebrew/bin//gmake to ~/bin/make and put ~/bin first in my path then it defaults to using my copy $ which -a make /Users/barrysmith/bin//make /opt/homebrew/bin//make /usr/bin/make ~/Src/petsc (barry/2023-05-14/add-fortran-petsccheck=) arch-add-fortran-petsccheck $ make --version GNU Make 4.4.1 Now I get Jed's behavior when I type make This security feature of /usr/bin/make has been true on macOS for many years, I had just mostly forgotten about it since I had ~/bin first in my path > On May 24, 2023, at 10:37 AM, Barry Smith <bsm...@petsc.dev> wrote: > > > Ahh, are you using the default make that comes from Apple or do you use a > modern gnumake (such as from brew?) > > I get Jed's results with the brew one (installed as gmake) and your results > with the Apple one /usr/bin/make > > > > >> On May 24, 2023, at 8:52 AM, Matthew Knepley <knep...@gmail.com> wrote: >> >> On Wed, May 24, 2023 at 6:53 AM Matthew Knepley <knep...@gmail.com >> <mailto:knep...@gmail.com>> wrote: >>> On Tue, May 23, 2023 at 9:00 PM Jed Brown <j...@jedbrown.org >>> <mailto:j...@jedbrown.org>> wrote: >>>> I use it that way all the time, but I can't reproduce. >>>> >>>> $ touch src/snes/interface/snes.c >>>> $ make test gs=snes_tutorials-ex5_1 >>>> CC ompi/obj/snes/interface/snes.o >>>> Using MAKEFLAGS: -j8 -l12 --jobserver-auth=fifo:/tmp/GMfifo1004133 -- >>>> gs=snes_tutorials-ex5_1 >>>> CLINKER ompi/lib/libpetsc.so.3.019.1 >>>> CLINKER ompi/tests/snes/tutorials/ex5 >>>> TEST ompi/tests/counts/snes_tutorials-ex5_1.counts >>>> ok snes_tutorials-ex5_1 >>>> ok diff-snes_tutorials-ex5_1 >>> >>> Does not work for me. This is incredibly frustrating: >>> >>> bldenton/dmplex-cadrefactor *$:/PETSc3/petsc/petsc-dev$ touch >>> src/snes/interface/snes.c >> >> Found it. For some reason, I need >> >> make -f./gmakefile test >> >> Matt >> >>> bldenton/dmplex-cadrefactor $:/PETSc3/petsc/petsc-dev$ make test >>> gs=snes_tutorials-ex5_1 >>> /usr/bin/make --no-print-directory -f >>> /PETSc3/petsc/petsc-dev/gmakefile.test PETSC_ARCH=arch-master-debug >>> PETSC_DIR=/PETSc3/petsc/petsc-dev test >>> /Library/Frameworks/Python.framework/Versions/3.8/bin/python3 >>> /PETSc3/petsc/petsc-dev/config/gmakegentest.py >>> --petsc-dir=/PETSc3/petsc/petsc-dev --petsc-arch=arch-master-debug >>> --testdir=./arch-master-debug/tests >>> Using MAKEFLAGS: --no-print-directory -- PETSC_DIR=/PETSc3/petsc/petsc-dev >>> PETSC_ARCH=arch-master-debug gs=snes_tutorial >>> s-ex5_1 >>> CC arch-master-debug/tests/snes/tutorials/ex5.o >>> CLINKER arch-master-debug/tests/snes/tutorials/ex5 >>> TEST arch-master-debug/tests/counts/snes_tutorials-ex5_1.counts >>> ok snes_tutorials-ex5_1 >>> ok diff-snes_tutorials-ex5_1 >>> >>> Thanks, >>> >>> Matt >>> >>>> Barry Smith <bsm...@petsc.dev <mailto:bsm...@petsc.dev>> writes: >>>> >>>> > Sure, I do also with make all; make test s="something" >>>> > >>>> > I have no idea how gmakefile.test dependencies work, you'll need to >>>> > get Jed to fix the problem. >>>> > >>>> > >>>> > >>>> >> On May 23, 2023, at 10:22 AM, Matthew Knepley <knep...@gmail.com >>>> >> <mailto:knep...@gmail.com>> wrote: >>>> >> >>>> >> On Tue, May 23, 2023 at 10:22 AM Barry Smith <bsm...@petsc.dev >>>> >> <mailto:bsm...@petsc.dev> <mailto:bsm...@petsc.dev >>>> >> <mailto:bsm...@petsc.dev>>> wrote: >>>> >>> >>>> >>> I never knew there was such a dependency; I always ran make all ; >>>> >>> make tests The gnumake stuff is still confusing to me so I have no >>>> >>> idea how it works or why. >>>> >> >>>> >> I run single tests all the time. That is how I develop. >>>> >> >>>> >> Matt >>>> >> >>>> >>>> On May 23, 2023, at 9:34 AM, Matthew Knepley <knep...@gmail.com >>>> >>>> <mailto:knep...@gmail.com> <mailto:knep...@gmail.com >>>> >>>> <mailto:knep...@gmail.com>>> wrote: >>>> >>>> >>>> >>>> The 'test' target no longer depends on 'libs' somehow so when I >>>> >>>> change source files they do not get rebuilt before my test runs. Why >>>> >>>> did we do this? >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> Matt >>>> >>>> >>>> >>>> -- >>>> >>>> What most experimenters take for granted before they begin their >>>> >>>> experiments is infinitely more interesting than any results to which >>>> >>>> their experiments lead. >>>> >>>> -- Norbert Wiener >>>> >>>> >>>> >>>> https://www.cse.buffalo.edu/~knepley/ >>>> >>>> <http://www.cse.buffalo.edu/~knepley/> >>>> >>> >>>> >> >>>> >> >>>> >> -- >>>> >> What most experimenters take for granted before they begin their >>>> >> experiments is infinitely more interesting than any results to which >>>> >> their experiments lead. >>>> >> -- Norbert Wiener >>>> >> >>>> >> https://www.cse.buffalo.edu/~knepley/ >>>> >> <http://www.cse.buffalo.edu/~knepley/> >>> >>> >>> -- >>> What most experimenters take for granted before they begin their >>> experiments is infinitely more interesting than any results to which their >>> experiments lead. >>> -- Norbert Wiener >>> >>> https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/> >> >> >> -- >> What most experimenters take for granted before they begin their experiments >> is infinitely more interesting than any results to which their experiments >> lead. >> -- Norbert Wiener >> >> https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/> >
