gpmueller / clang-build-test Goto Github PK

A project may contain multiple files with the same name in different subdirectories, so the compile and link commands need to include these subdirectories.

Either via the rule that if sources are specified directly, directories will not be globbed, or via a switch, e.g. search_directories.
Some stupid project layouts have a lot of stuff mixed in a single folder and it may be better to allow this. Unit test .cpp files are generally gathered in a single folder, too.

This package wants to be easy to use. Therefore, a pip installation is a must have feature. It should also setup a command-line interface so people can call it directly without python3 -m .... See also here: http://setuptools.readthedocs.io/en/latest/setuptools.html#automatic-script-creation

For example: a project may define various library targets, which should only be built if actually used (e.g. either a c-interface or a c++-interface).
One may also not want to always build all test executables.

Should be able to parse a basic example such as

[myexe]
[myexe.sources]
include_directories = ["myexe/include"]
source_directories = ["myexe/src"]
[myexe.link]
dependencies = ["eigen"]
flags = ["-DEIGEN_NO_FAST_MATH"]

[eigen]
external = true
url = "https://github.com/eigenteam/eigen-git-mirror"

Their build system is far more generic, but their structuring of C/C++ targets is very reasonable:

• https://please.build/lexicon.html#cc
• https://please.build/config.html#cpp

Subprocess functions should not be called with shell=True (see e.g.: https://stackoverflow.com/questions/3172470/actual-meaning-of-shell-true-in-subprocess). This way you do not have to take care to tailor your call string to different platforms, among other benefits.

For this, a command line option -j should be added, so that e.g. -j4 could be used to create up to 4 parallel threads of build execution.
To make it work, it's merely necessary to spawn an appropriate number of threads when a targets compile/link has completed and the parents are called. Probably this should be done with a thread pool/queue, where it's continuously checked how many threads are currently running, threads are started if possible and the others kept waiting.

Currently, if a target and it's dependency both have e.g. -O3 as flag, it will appear twice, which may cause problems for some flags.

Currently you are using print statements everywhere. However, if you would use functions like the python logging stuff, you could set different output levels. So people who want to integrate your code into their toolchain could silence your output or select how much output they want.

The question is what should happen if no version is known or the build type is Default...

That aside, it would make sense to have paths such as build/release/targetname/1.0.0/ (with subdirectories for external_sources, obj/source_subfolder, lib, bin, include and possibly others).

For unknown versions, instead of a folder like v1.0.0 maybe vAny?

After resolving #14, it may be sensible to put files in folders called lib, bin and include (and, for that matter, copy export headers, analogous to CMake install).
The question is if all target build results should go into the same folder or, instead, folders lib/target1 etc. should be created.

Path separators shouldn't be hardcoded into your scripts. Although it works most of the times, there are modules like PathLib2 that take away all the hassle with python path separators. E.g. if you are on windows, you have a folder that starts with U and you manipulate those strings (like adding a filename to the end of the path), python will not like that newly created string (see here: https://docs.python.org/3/howto/unicode.html for the example I gave).

The build type Coverage was added, but has not yet been tested.

When traveling through the dependency graph, the build process should only be started when a target with updated sources or config is encountered.

As a first implementation, it should be enough to poll the modification dates and compare it to those in a cache file: https://stackoverflow.com/a/182259/4069571
E.g. a touch.toml could be written into the root of the builddir.

On Windows, if nothing is exported using __declspec(dllexport), no import library will be created (.lib file) and therefore the library cannot be linked.

Certain things should be cached:

• file modification dates
• last used build type?
• ...

A command line option --clean to empty the build directory and an option --clear to clear the cache before building might be useful. Maybe, when these options are passed, no build should be triggered.

Since external tools, such as moc, uic, rcc may need to be called, it may be necessary to introduce additional steps, such as pre_compile, post_compile and post_link, which will call a user-provided python script (if present).
The example would then contain a QT MWE and such an additional script which calls the required tools manually.

If this example were successful, it would prove the necessary versatility and applicability for this tool.

• http://doc.qt.io/qt-5/moc.html
• http://doc.qt.io/qt-5/uic.html
• http://doc.qt.io/qt-5/rcc.html

Currently, e.g. -Wall -Werror may appear multiple times in the build command, which can potentially re-activate errors that were deactivated for the currently built target.