freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Accounting for SHELL in ./configure


From: Behdad Esfahbod
Subject: Re: Accounting for SHELL in ./configure
Date: Wed, 1 May 2024 15:17:35 -0600

Scratch that.

Where is it exactly failing? On Unix, the build system is essentially autoconf, so it should respect SHELL as you suggest.



On Wed, May 1, 2024 at 3:15 PM Behdad Esfahbod <behdad@behdad.org> wrote:
Can you check if also setting CONFIG_SHELL helps?



On Wed, May 1, 2024 at 3:06 PM Mohammad Akhlaghi <mohammad@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 <behdad@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.


On Wed, May 1, 2024 at 2:45 PM Mohammad Akhlaghi <mohammad@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 <behdad@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.

On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi <mohammad@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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]