Re: [edk2-devel] edk2setup.sh shortcomings

["tlaronde@polynum.com" <tlaronde@polynum.com>]

Le Thu, Feb 02, 2023 at 05:50:32PM +0100, Gerd Hoffmann a écrit :
> On Thu, Feb 02, 2023 at 12:29:32PM +0100, tlaronde@polynum.com wrote:
> > edk2setup.sh has shortcomings. To list some:
> > 
> > 	- The functions return a status but it is not tested; hence the
> > 	  script goes to the end with a final "return $?" that simply
> > 	  returns the status of the last command that is "unset" which
> > 	  always successfully unsets, even a not set variable. Hence a
> > 	  script can not catch a failure by testing the end status that is
> > 	  always 0;
> > 	- If WORKSPACE is set, --reconfig does nothing;
> > 	- If EDK_TOOLS_PATH and PACKAGES_PATH are set, even to incorrect
> > 	  values, the script succeeds even if BaseTools/ is not found
> > 	  anywhere;
> > 	- The comments are obsolete (1): bash(1) is required because the syntax
> > 	  is not POSIX.2 sh(1) compliant and because some Makefile recipes
> > 	  have "bash'isms" (indeed, a GMAKE variable should be exported
> > 	  with a definition of "/path/to/gnu/make SHELL=/path/to/bash" and
> > 	  a canonical call should be "$GMAKE ...");
> > 	- The comments are obsolete (2): CYGWIN is not treated in anyway
> > 	  specifically and, on the contrary, the regexp translation of ':'
> > 	  in spaces for PACKAGES_PATH would be sure to create a mess with
> > 	  a MS Windows like path;
> >  	- The settings have obviously evolved and the help message does not
> > 	  list all the variables that can be set and that do modify the
> > 	  way the setting is done;
> > 	- Some commands (notably whereis(1)) are not standard utilities, not
> > 	  to be found on all Unix like systems and, even if found, have
> > 	  greatly diverging behaviors.
> > 
> > What is the preferred procedure?
> 
> Ignore it and to just use BaseTools/BuildEnv directly?
> I'm not fully sure what value it adds ...

That's the problem: it does not add much, but it adds some things and
the problem (for me) is to know if these are used or not:

1) It exports PYTHONHASHSEED=1 (needed?);
2) Undocumented features allow to use something else instead of
BaseTools/BuildEnv...

I also think that it would be far better to state clearly what is
needed (including with BaseTools/BuildEnv and the
like) and let builders simply set the correct environment with
defined variables being used afterwards (MAKE, SHELL, PYTHON and
so on).

To state, for example the Python major version required and that
everything depends on GNU make and bash(1) (hence the
/path/to/gnu/make SHELL=/path/to/bash invocation) and that
would be it.

But: who uses it (edk2setup.sh) and with what? This question, I can not
answer, obviously...

> 
> > Should I file BZ to list all the
> > problems so that someone authorized may address them? Or can I propose
> > a patch to address these (keeping it backward compatible with a present
> > correct use) with a reasonable hope that, as an exception that will not
> > become a rule, it will not be ignored?
> 
> Sending patches has a much higher chance to succeed, although there is
> no guarantee unfortunately.

Hum... There is a very lethal weapon actually in use: the pillow. I
already sent various patches and they are silently ignored...

If my contribution will be ignored as others have been till now, honesty
should be to clearly state: "we don't care and we won't care" so that
I can use my time trying to solve the problems I want to address at a 
different level than UEFI...

Best,
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C