I know all that. :) Check out builds/unix/configure.ac behdad http://behdad.org/
On Wed, May 1, 2024 at 4:40 PM Mohammad Akhlaghi <moham...@akhlaghi.org> wrote: > I had set the 'SHELL' environment variable but still '/bin/sh' was used. > The only way I could pass my SHELL to the Make command within the > configure script was through the non-standard hack I mentioned before: > GNUMAKE="make SHELL=$SHELL" > > Autoconf generates the './configure' script automatically though a > 'configure.ac' file. But I don't see any 'configure.ac' in FreeType's > source. For example here is the source code of a project that I maintain > which uses Autoconf: > > https://git.savannah.gnu.org/cgit/gnuastro.git/tree > > The './configure' script is generated automatically from 'configure.ac' > when building the tarball (since the configure script is automatically > generated, we don't keep it under version control). > > Cheers, > Mohammad > > On 5/1/24 11:17 PM, Behdad Esfahbod wrote: > > Scratch that. > > > > Where is it exactly failing? On Unix, the build system is essentially > > autoconf, so it should respect SHELL as you suggest. > > > > behdad > > http://behdad.org/ > > > > > > On Wed, May 1, 2024 at 3:15 PM Behdad Esfahbod <beh...@behdad.org> > wrote: > > > >> Can you check if also setting CONFIG_SHELL helps? > >> > >> behdad > >> http://behdad.org/ > >> > >> > >> On Wed, May 1, 2024 at 3:06 PM Mohammad Akhlaghi <moham...@akhlaghi.org > > > >> wrote: > >> > >>> The Autoconf-generated configure script, or even CMake, respect SHELL, > so > >>> if a user gives it a problematic shell, they won't be able to build > >>> anything abd many programs will crash. > >>> > >>> But please consider the scenario mentioned before: when a user doesn't > >>> have root permissions to change '/bin/sh', they are left with > non-standard > >>> hacks like what I did. > >>> > >>> When each program's build system respects 'SHELL', the user is free to > >>> use any shell they want with any program's build. > >>> > >>> Cheers, > >>> Mohammad > >>> > >>> > >>> > >>> > >>> On May 1, 2024 10:55:05 PM GMT+02:00, Behdad Esfahbod < > beh...@behdad.org> > >>> wrote: > >>> > >>>> I'm not talking about the user overriding the shell specifically. I'm > >>>> talking about users who genuinely use a non-POSIX shell as their > terminal > >>>> shell. Then just running ./configure would fail if configure was to > respect > >>>> $SHELL. > >>>> > >>>> Or rather you're saying that only POSIX-compatible shells should set > >>>> $SHELL. > >>>> behdad > >>>> http://behdad.org/ > >>>> > >>>> > >>>> On Wed, May 1, 2024 at 2:45 PM Mohammad Akhlaghi < > moham...@akhlaghi.org> > >>>> wrote: > >>>> > >>>>> Thanks Behdad, > >>>>> > >>>>> The problem is that I do not have root permissions on the system with > >>>>> the faulty '/bin/sh': I cannot change '/bin/sh' and need to build my > >>>>> programs with a custom shell. > >>>>> > >>>>> If the user specifies a wrong shell (not the default '/bin/sh'), it > is > >>>>> their own responsibility that it is POSIX-compatible. The same way > that a > >>>>> user can give a non-GNU Make executable to the GNUMAKE variable. > >>>>> > >>>>> In short, when a user changes defaults, it is their resposibility, > not > >>>>> the developer's. So no need to worry about that; the important thing > is to > >>>>> give users the freedon to customize for their custom environments > (as GNU > >>>>> Autoconf does for example; but Autoconf is not used in FreeType). > >>>>> > >>>>> Cheers, > >>>>> Mohammad > >>>>> > >>>>> > >>>>> > >>>>> On May 1, 2024 10:25:54 PM GMT+02:00, Behdad Esfahbod < > >>>>> beh...@behdad.org> wrote: > >>>>> > >>>>>> There's no guarantee that the user's shell is sh-compatible. > autoconf > >>>>>> really means sh here, because that's the shell the script is > written for. > >>>>>> Just symlink your favorite shell to sh then, if it's compatible. > >>>>>> > >>>>>> behdad > >>>>>> http://behdad.org/ > >>>>>> > >>>>>> > >>>>>> On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi < > >>>>>> moham...@akhlaghi.org> wrote: > >>>>>> > >>>>>>> Hi again, > >>>>>>> > >>>>>>> I was able to find a cleaner hack by running this command before > the > >>>>>>> './configure' script: > >>>>>>> > >>>>>>> export GNUMAKE="make SHELL=$SHELL" > >>>>>>> > >>>>>>> Afterwards, FreeType successfully ran with my desired shell. > >>>>>>> > >>>>>>> But generally, it would greatly help those building FreeType from > >>>>>>> source > >>>>>>> if the configure script accounts for the 'SHELL' environment > variable. > >>>>>>> > >>>>>>> Thanks a lot for all the nice work on FreeType, > >>>>>>> Cheers, > >>>>>>> Mohammad > >>>>>>> > >>>>>>> On 5/1/24 9:00 PM, Mohammad Akhlaghi wrote: > >>>>>>>> Dear Freetype developers, > >>>>>>>> > >>>>>>>> I was trying to build FreeType from source and noticed that the > >>>>>>>> './configure' script does not account for the 'SHELL' environment > >>>>>>> and > >>>>>>>> will always use '/bin/sh'. > >>>>>>>> > >>>>>>>> Looking at the source of the './configure' script, I was able to > >>>>>>> fix the > >>>>>>>> problem by manually adding a 'SHELL=$SHELL' in line 135 of the > >>>>>>>> './configure' script: > >>>>>>>> > >>>>>>>> > >>>>>>> > https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/configure?ref_type=heads#L135 > >>>>>>>> > >>>>>>>> Accounting for the user's given SHELL is common in many programs > >>>>>>> when > >>>>>>>> building from source, so it would be good if you could account for > >>>>>>> it in > >>>>>>>> future versions of FreeType also. > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> Mohammad > >>>>>>> > >>>>>>> > > >
