aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/bin/init.cxx
AgeCommit message (Collapse)AuthorFilesLines
2022-10-10Preparatory work for public/private variable distinctionBoris Kolpackov1-0/+4
We still always use the public var_pool from context but where required, all access now goes through scope::var_pool().
2022-06-24Make libul{} rule match without hintBoris Kolpackov1-5/+1
In the end, the extra jumping through the hoops doesn't justify the extra safety we gain. The only plausible accidental mistake is making libul{} a dependency of ./ but then we don't prevent the same for libue{}, which also doesn't make much sense. Though, the consequences of doing this for libul{} could be more severe, like messed up for-install'ness. Oh, well, I guess people will just have to pay attention (this could be a good check for the linter we've been thinking about).
2022-06-24Match rule to libul{} with explicit bin.metadata hintBoris Kolpackov1-1/+5
This rule picks, matches, and unmatches (if possible) a member for the purpose of making its metadata (for example, library's poptions, if it's one of the cc libraries) available.
2022-04-06Add support for rule hintsBoris Kolpackov1-4/+2
A rule hint is a target attribute, for example: [rule_hint=cxx] exe{hello}: c{hello} Rule hints can be used to resolve ambiguity when multiple rules match the same target as well as to override an unambiguous match.
2021-10-11Update bin.lib.version documentationBoris Kolpackov1-3/+0
2021-06-30Move symbol exporting .def file rule to bin.def module, add support for MinGWBoris Kolpackov1-16/+34
The bin.def module is automatically loaded by the c and cxx modules for the *-win32-msvc target architecture. This allows automatically exporting all symbols for all Windows targets using the following setup (showing for cxx in this example): lib{foo}: libul{foo}: {hxx cxx}{**} ... lib{foo}: def{foo}: include = ($cxx.target.system == 'win32-msvc') def{foo}: libul{foo} if ($cxx.target.system == 'mingw32') cxx.loptions += -Wl,--export-all-symbols That is, we use the .def file generation for MSVC and the built-in support (--export-all-symbols) for MinGW. But it is also possible to use the .def file generation for MinGW. In this case we need to explicitly load the bin.def module (which should be done after loading c or cxx) and using the following setup: using bin.def # In root.build. lib{foo}: libul{foo}: {hxx cxx}{**} ... lib{foo}: def{foo}: include = ($cxx.target.class == 'windows') def{foo}: libul{foo}
2021-06-21Add support for automatic generation of symbol exporting .def fileBoris Kolpackov1-0/+127
2021-04-20Detect environment changes in ad hoc recipesBoris Kolpackov1-8/+20
2021-04-07Register environment variables for hermetic build configurationsBoris Kolpackov1-0/+8
2021-01-30Add std::{map, multimap} to types.hxxBoris Kolpackov1-2/+0
Seeing that std::map is becoming a common Buildfile variable type.
2021-01-22Redo bin.lib.version not to require empty keyBoris Kolpackov1-2/+5
2021-01-11Fix libul{} rule diagnosticsBoris Kolpackov1-9/+10
2020-12-15Cache more results of executing programs (compilers, etc)Boris Kolpackov1-28/+23
2020-12-11Add support for module interface-only librariesBoris Kolpackov1-5/+16
Also suppress generation of the object file in cases where we don't need it.
2020-11-12Assign fixed extensions to wasm{} and pdb{} target typesBoris Kolpackov1-2/+28
2020-11-06Resolve warningBoris Kolpackov1-1/+1
2020-11-06Keep executable bit on .wasm files when installingBoris Kolpackov1-2/+4
2020-11-05Initial Emscripten supportBoris Kolpackov1-138/+153
- Target: wasm32-emscripten (wasm32-unknown-emscripten). - Compiler id: clang-emscripten (type clang, variant emscripten, class gcc). - Ability to build executables (.js plus .wasm) and static libraries (.a). Set executable bit on the .js file (so it can be executed with a suitable binfmt interpreter). - Default config.bin.lib for wasm32-emscripten is static instead of both. - Full C++ exception support is enable unless disabled explicitly by the user with -s DISABLE_EXCEPTION_CATCHING=1|2. - The bin module registers the wasm{} target type for wasm32-emscripten.
2020-08-24Use representation when passing target_triplet as hintBoris Kolpackov1-1/+1
2020-06-18Complete NetBSD compatibilityBoris Kolpackov1-1/+1
2020-06-18Add NetBSD compatibilitymagenbluten1-1/+1
2020-06-16Add $bin.link_member() functionBoris Kolpackov1-2/+14
Given a linker output target type ("exe", "lib[as]", or "libu[eas]") return the target type of lib{} group member ("liba" or "libs") that will be picked when linking a lib{} group to this target type.
2020-06-02Add process_path_ex with program stable name and checksumBoris Kolpackov1-14/+16
2020-05-22Make template definition available in all translation units where usedBoris Kolpackov1-1/+1
We were trying to be clever but GCC 10's IPA-SRA optimization didn't like it.
2020-04-27Rework tool importation along with cli moduleBoris Kolpackov1-1/+1
Specifically, now config.<tool> (like config.cli) is handled by the import machinery (it is like a shorter alias for config.import.<tool>.<tool>.exe that we already had). And the cli module now uses that instead of custom logic. This also adds support for uniform tool metadata extraction that is handled by the import machinery. As a result, a tool that follows the "build2 way" can be imported with metadata by the buildfile and/or corresponding module without any tool-specific code or brittleness associated with parsing --version or similar outputs. See the cli tool/module for details. Finally, two new flavors of the import directive are now supported: import! triggers immediate importation skipping any rule-specific logic while import? is optional import (analogous to using?). Note that optional import is always immediate. There is also the import-specific metadata attribute which can be specified for these two import flavors in order to trigger metadata importation. For example: import? [metadata] cli = cli%exe{cli} if ($cli != [null]) info "cli version $($cli:cli.version)"
2020-03-31Fix bug in install_path() call (Windows-specific)Boris Kolpackov1-2/+6
2020-03-31Switch to project variable visibility by defaultBoris Kolpackov1-30/+27
2020-03-17Rework config::{omitted,required,optional}() into unified config_lookup()Boris Kolpackov1-72/+76
2020-03-11Minor config variable lookup cleanupsBoris Kolpackov1-4/+4
2020-02-24Extract version for lld-linkBoris Kolpackov1-4/+33
2020-02-07Drop copyright notice from source codeKaren Arutyunov1-1/+0
2020-01-29Rename module_base to module, redo module boot/init argument passingBoris Kolpackov1-30/+21
2020-01-28Use scope::var_pool()Boris Kolpackov1-12/+12
2020-01-28Use scope::insert_rule()Boris Kolpackov1-2/+2
2020-01-27See through lib{} group during distBoris Kolpackov1-1/+6
2020-01-27Improve module loading APIBoris Kolpackov1-26/+12
2019-11-12Infra work for customizable config var persistence (config.config.persist)Boris Kolpackov1-1/+1
2019-10-29Add support for specifying custom load prefix and version clean patternsBoris Kolpackov1-5/+14
2019-10-09Prepend pattern search paths to PATH when running binutilsBoris Kolpackov1-24/+1
This way any dependent tools (such as mt.exe that is invoked by link.exe) are first search for in there.
2019-10-09Work around issue with undefined symbol to constexpr constBoris Kolpackov1-1/+1
Note that this only manifests itself when compiling in the C++14 mode (e.g., during bootstrap or with an older compiler like GCC 4.9).
2019-10-08Redo bin pattern as PATH-like search paths rather than fallback directoryBoris Kolpackov1-23/+39
Also, unlike the fallback directory, the search paths are searched first rather than last.
2019-08-28Move bin build system module to separate libraryKaren Arutyunov1-0/+963
generated by cgit v1.1 at 2024-11-14 15:10:46 +0000