Re: [MiNT] mintlib Makefile requires bash as shell

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On Sunday 18 October 2009, Vincent Rivière wrote:
> Here is the base problem.
> The MiNTLib wants to be compiled with -nostdinc to avoid conflicts with
> the already installed libc headers. But it still needs the headers
> provided by the compiler itself (like stdddef.h, float.h...). So it uses
> gcc --print-search-dirs to get the gcc include directories. This process
> is slow, so the result needs to be cached somewhere; actually in the file
> includepath.
>
> Then that cached value has to be used when compiling the sources.
> Currently the file includepath is read for each C source, the fastest
> method being the bashism $(<file}
>
> Of course the best method would be to cache the includepath value in a
> make variable. But it is not possible, because the first time make is
> run, the includepath is determined,

Why?

I mean, why not just do as the first thing something like:
	INCLUDEPATH := $(shell gcc --print-search-dirs ...)
?

If MiNT uses sub-Makefiles[1], there are several ways to propagate this
information to the submakes:
- using tempororary make include files:
	echo INCLUDEPATH=$(INCLUDEPATH)  >  $(toplevel)/make.inc
  then in sub Makefiles:
	include make.inc
- using environment variables:
	INCLUDEPATH=$(INCLUDEPATH) $(MAKE) -C <subdir> ...

[1] Best way would be to do like Linux kernel does and let subdirs just
provide Makefile pieces which all get used by the main Makefile (if I've
understood how it all works together).  That way Make is aware of _all_
the dependencies, parallel builds work without problems etc.


> unfortunately (if I understood well) the make variables are read only.

I don't understand what this means, but even if that would be true,
you could use your own variables which contents you give to gcc?


> In traditional packages, there is a configure script which gathers all
> that kind of system parameters that will be used by the Makefiles. But in
> case on the MiNTLib, the makefiles want to be standalone and configure
> themselves, that leads to these kinds of difficulties.

Makefiles can do that themselves as well, there's nothing magical about
what Autotools does (IMHO it's actually pretty horrible).   "configure"
is  just a shell script created from m4 macros etc.  Makefile can do all
the same work too.

Nowadays that everything provides pkg-config files, configure isn't needed
for checking the existence dependencies and their versions.  If one keeps to
standard C and supports only gcc[1] & sane operating systems[2] as targets,
I don't really see any value in Autotools.  It just makes code less portable
to smaller platforms[2], slows down building[1] and complicates debugging of
build issues[2].



	- Eero

<oh boy, here we go again... somehow I end up Bashing Autotools...>

[1] Compiler check is one of the things configure does, few years ago it
also unconditionally spent quite a while checking which Fortran compilers
you had installed...  And added libXt dependency to everything checking
Xlibs with autotools.  And...

[2] Autotools developers WONTFIX bugs about it not checking existence of
external tools they use (diff etc that are specified in POSIX but not
properly supported e.g. by Busybox), but they make the configure scripts
unreadable by expecting shell not to be POSIX compliant and support POSIX
shell functions...