[Tinycc-devel] some thoughts on the search path mess

[Edmund Grimley Evans]

Currently the search paths for a non-cross tcc on Debian arm64 look
like this (./tcc -vv):

crt:
  /usr/lib/aarch64-linux-gnu
libraries:
  /usr/lib/aarch64-linux-gnu
  /usr/lib
  /lib/aarch64-linux-gnu
  /lib
  /usr/local/lib/aarch64-linux-gnu
  /usr/local/lib
include:
  /usr/local/include/aarch64-linux-gnu
  /usr/local/include
  /usr/include/aarch64-linux-gnu
  /usr/include
  /usr/local/lib/tcc/include

Does that seem correct?

I note that /usr/local/lib comes after /usr/lib, but
/usr/local/include comes before /usr/include. Why is that?

Also, should /usr/lib be on the search path for crt?

Also, is it correct for /usr/local/lib/tcc/include to come last rather
than first in the "include" list?

Presumably the search paths for any other Debian architecture could be
the same with the appropriate triplet substituted for
"aarch64-linux-gnu".

Now, it seems that some other Linux distributions use lib32 and lib64.
Is that only on Intel, or do they do the same on other architectures
that have 32-bit and 64-bit variants?

What should the search paths look like on one of those Linuxes?

A general question: should "configure" try to work out what kind of
Linux we're on, or it should it just merrily include all the
possibilities in the search paths?

The situation for a cross compiler is mostly very similar, except:

* You can't run a test program. But TCC's configure doesn't do that
  anyway.

* There's no point in including generic paths like /usr/lib in the
  search paths. They are almost certainly wrong. However, if you're
  cross-compiling between variants of the same architecture then it
  probably make sense to include things like /usr/lib32 in the paths.

* With a cross-compiler it's quite probable that the user will install
  libraries after building TCC so it perhaps makes more sense to
  include directories that don't yet exist in the search paths.

That last point suggests that for symmetry between cross and non-cross
compilers it might make sense to put, by default, all likely
directories into the search path whether or not they exist.

Another general point: You can put complex "sh" logic in "configure",
complex "make" logic in "Makefile", or complex "cpp" logic in the C
source files: a choice of three crap programming languages! If you're
a masochist, you can also put double-escaped sh code in the Makefile.
Also, you can make the logic at each stage attempt to pre-empt bzw.
second-guess what the logic at other stages has done or will do. I
tend to think that "configure" is probably the best place to do things
as "sh" is arguably the least hostile of the three environments. Also,
configure produces a human-readable output and you can insert print
statement into it, both of which help with debugging.

Thoughts?

Edmund