[libc-dev] Top-level test directory

[Siva Chandra via libc-dev]

Hello all,

Back during the review of my very first patch to llvm-libc, it was
pointed out that other LLVM projects use a top-level `test` directory
for tests. I had then said that it would be better to keep the tests
next to implementation and started putting tests next to the
implementations. However, I have hit a limitation with such a scheme.
It isn't really a limitation of the scheme itself, but of CMake.

The limitation is like this: The main libc functions are compiled into
object files using the add_entrypoint_object rule. These object files
are either linked into the test executable testing them, or archived
into libc.a (for Linux for example). If one implementation uses
another one, then the tests have to link to both the implementation
object files, potentially coming from different directories. This
makes the test directory order dependent causing cyclic directory
cross-referencing [*] even though there are no cyclic dependencies.

To avoid the above problem, I would like to ditch the "tests near the
implementation" scheme and adopt the rest-of-LLVM pattern of putting
tests in a top-level `test` directory. This way, the test directory
can be the last directory added using `add_subdirectory`, and
therefore will have all the targets of the implementations available.

Within the `test` directory, the directory tree will follow the same
structure as that of the rest of the project:

- test
    |
   <>--- src
    |       |
    |      <>--- string
    |       |
    |      <>--- errno
    |        ...
   <>--- config
             |
            <>--- linux
                     |
                    <>--- x86_64
             ....

WDYT?

Thanks,
Siva Chandra

[*] CMake can in general can handle cyclic directory
cross-referencing, but one cannot use commands like
get_target_property on targets which CMake has not yet seen. We
need/use commands like this to convey information to consumers, for
example, of add_entrypoint_object targets.