It is much harder to spot stuff in a long string. When every file is printed on a separate line it is visually much simple to search through it, recognize missing files and wrong prefixes/suffixes.
* test suite fixes for link=static default
* emscripten renovation
* inherit from clang toolset
* update for 'new' fastcomp backend
* exceptions support
* dynamic linking support
* pthread support
* run-tests launcher via nodejs
total 79.2 -> 13.2 (6.0x)
self 34.2 -> 8.1 (4.2x)
target.actual-name is an ideal cache key because it is already used to register targets in the build engine which requires on it to be unique enough to not collide, while also is the shortest unique identifying string which is for a file targets consists of the target relevant properties, path prefix and name.
Co-authored-by: René Ferdinand Rivera Morell <grafikrobot@gmail.com>
I've setup CI on GHA because it is much more convenient using their action script.
This covers different Mingw setups and it does not fail on PCH tests like Mingw-w64 one installed by default on GHA/Azure (either because GCC exe there was built without ASLR or is a new recent version which supports PCH relocation).
* Add automatic project searching.
This adds an automatic, but controlled, method for finding, declaring,
and loading of unknown rooted project-id references.
(cherry picked from commit 3f6dd2dee29a0a0d89a4c83bc16abbd3977453e8)
* Fix incorrect project search env var name.
(cherry picked from commit 87c35a56d1a1d1fbb16e02d6c1101cdcd2e8c2b7)
* Fix infinite recursion when project path has "..".
(cherry picked from commit 4a7c4156df8295d442373b4feb99d426b55a887b)
* Fix use of >4.x native built-in.
---------
Co-authored-by: Rene Rivera <grafikrobot@gmail.com>
When configuring all msvc toolsets we would configure the ones from the registry followed by known location versions. This had the effect of making msvc versions from the registry the default over the pathed ones. Since the newer releases, after 14.0, don't use the registry it meant that even if you had new ones it would pick 14.0 (or earlier) as the default. This change tries to register them with registry and pathed each. Which results in preserving the new-to-old ordering. Resulting in the newest being the default, as intended.
(cherry picked from commit 0298977a9f3efe2f12e661a29f8fe3105cb6b0d8)
Co-authored-by: René Ferdinand Rivera Morell <grafikrobot@gmail.com>
It's possible, and common in Boost, to register projects using native paths (usually from env vars). That would cause incorrect tracking of the projects and result in failing to find them. This change converts the native path to a b2 path for registration. Which resolves finding them when it comes to loading the used projects.
(cherry picked from commit 80e5026a277a77daafe52c26ff589d0e22fb9c82)
Co-authored-by: René Ferdinand Rivera Morell <grafikrobot@gmail.com>
[ski ci]
When configuring all msvc toolsets we would configure the ones from the registry followed by known location versions. This had the effect of making msvc versions from the registry the default over the pathed ones. Since the newer releases, after 14.0, don't use the registry it meant that even if you had new ones it would pick 14.0 (or earlier) as the default. This change tries to register them with registry and pathed each. Which results in preserving the new-to-old ordering. Resulting in the newest being the default, as intended.
It's possible, and common in Boost, to register projects using native paths (usually from env vars). That would cause incorrect tracking of the projects and result in failing to find them. This change converts the native path to a b2 path for registration. Which resolves finding them when it comes to loading the used projects.
Boost@develop `b2 --layout=versioned -n install -d+10`
build was now sequence.unique
clean 594 -> 230 (2.6x) 366 -> 1.29 (284x)
rerun 547 -> 182 (3.0x) 362 -> 1.27 (285x)
I've changed unification in generators to be stable because it is faster somehow (by 33% vs non-sorting non-stable unique, by 180% vs sorting unique), plus it is preferable that targets are built in the order of declaration.
One example of this is gcc.cygwin/mingw.link which sets rule name to gcc.link. If you let clang-linux inherit such generator -- clone would just reset the name to new-id and execution will fail with attempt to call non-existing clang-linux.cygwin/mingw.link rule.
(cherry picked from commit ca686f2042e57da4efe360aabd0f2f6017946cca)
Co-authored-by: Nikita Kniazev <nok.raven@gmail.com>
[skip ci]
One example of this is gcc.cygwin/mingw.link which sets rule name to gcc.link. If you let clang-linux inherit such generator -- clone would just reset the name to new-id and execution will fail with attempt to call non-existing clang-linux.cygwin/mingw.link rule.
`<linker>` override is preserved and passed to clang as the linker to use.
(cherry picked from commit 2398110169f3553ba76afe351fb1d411470baf92)
Co-authored-by: Nikita Kniazev <nok.raven@gmail.com>
[skip ci]
-mthreads is obsolete and is not presented in clang, and was never a thing in cygwin (fixes#38).
I have no idea why clang was configured to add -pthread on threadapi=win32, changing this is a breaking change but is the right thing to do. I run Boost.Thread tests and it passed cleanly on both threadapi=win32 and threadapi=pthread.
(cherry picked from commit 308bdd509d47cfed5e25bda747cb9e6c6a93b790)
Co-authored-by: Nikita Kniazev <nok.raven@gmail.com>
[skip ci]
-mthreads is obsolete and is not presented in clang, and was never a thing in cygwin (fixes#38).
I have no idea why clang was configured to add -pthread on threadapi=win32, changing this is a breaking change but is the right thing to do. I run Boost.Thread tests and it passed cleanly on both threadapi=win32 and threadapi=pthread.
* update tag test to check pdbs too
* pdb order issues tentative fix
* use usual name generation machinery for pdbs
I believe this is the root cause of mysterious bugs involving pdbs:
1. `replace-targets` may rearrange targets order, which might be the cause of
exe/dll/lib swapping places.
2. The hack in `msvc-linking-generator` were messing things up somehow when
`virtual-target.register` returns a cached target.
Even if the change does not fix these issues it is still a good code refactor.
Co-authored-by: Nikita Kniazev <nok.raven@gmail.com>
[skip ci]
* update tag test to check pdbs too
* pdb order issues tentative fix
I believe this is the root cause of mysterious bugs involving pdbs:
1. `replace-targets` may rearrange targets order, which might be the cause of
exe/dll/lib swapping places.
2. The hack in `msvc-linking-generator` were messing things up somehow when
`virtual-target.register` returns a cached target.
Even if the change does not fix these issues it is still a good code refactor.
* use usual name generation machinery for pdbs
Rearranging to `SHARED_LIB IMPORT_LIB` order makes `$(<[2])` always an implib and allows to drive `--out-implib` by generator directly without any chances to produce an implib with the main generator which is not meant to produce them.
(cherry picked from commit f31180a77709c68e49c040b8028eb8e605c97874)
Co-authored-by: Nikita Kniazev <nok.raven@gmail.com>
Rearranging to `SHARED_LIB IMPORT_LIB` order makes `$(<[2])` always an implib and allows to drive `--out-implib` by generator directly without any chances to produce an implib with the main generator which is not meant to produce them.
Removes additional point of failure, the need for actual toolset to be available, and speeds up mock tests considerably.
A bit disgusting solution, could be improved by removing limitation where toolsets take into account only first `<archive>` value.
(cherry picked from commit 6d5e150f1e17562a8efe2f396914da8123a9917a)
Co-authored-by: Nikita Kniazev <nok.raven@gmail.com>
Removes additional point of failure, the need for actual toolset to be available, and speeds up mock tests considerably.
A bit disgusting solution, could be improved by removing limitation where toolsets take into account only first `<archive>` value.
There are a few hacks to preserve quick Ctrl-C behavior.
I also added timings to the output and progress numbers.
(cherry picked from commit 948482fa9a355d9e425613b378415077e8e730b4)
Co-authored-by: Nikita Kniazev <nok.raven@gmail.com>
