aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/bin
AgeCommit message (Collapse)AuthorFilesLines
2021-10-27Handle "common symbols" in symbol exporting .def generation ruleBoris Kolpackov1-15/+53
2021-10-14Use tidier pc and def names instead of generic gen for .pc and .def generationBoris Kolpackov1-1/+1
2021-10-11Update bin.lib.version documentationBoris Kolpackov1-3/+0
2021-06-30Complete nm detectionBoris Kolpackov2-7/+22
2021-06-30Move symbol exporting .def file rule to bin.def module, add support for MinGWBoris Kolpackov3-153/+284
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 Kolpackov6-3/+910
2021-05-04Replace int_ with intf_ and imp_ with impl_ in namesBoris Kolpackov1-2/+2
2021-04-22Incorporate project environment checksum into cc::compiler_info cache keyBoris Kolpackov2-0/+21
2021-04-20Detect environment changes in ad hoc recipesBoris Kolpackov1-8/+20
2021-04-20Disable bunch of bogus GCC warningsBoris Kolpackov1-3/+0
2021-04-07Register environment variables for hermetic build configurationsBoris Kolpackov3-4/+69
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 Kolpackov3-16/+44
2020-12-15Cache more results of executing programs (compilers, etc)Boris Kolpackov3-55/+111
2020-12-11Add support for module interface-only librariesBoris Kolpackov3-12/+27
Also suppress generation of the object file in cases where we don't need it.
2020-12-04Fix bug in installed libraries matching logicBoris Kolpackov2-3/+7
2020-12-04Mark Buildfile functions as pure or impureBoris Kolpackov1-1/+3
2020-12-03Fix modules support for installed librariesBoris Kolpackov2-7/+3
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-07-13Add ability to extend rule interface in source-compatible mannerBoris Kolpackov1-2/+2
2020-06-18Complete NetBSD compatibilityBoris Kolpackov2-1/+6
2020-06-18Add NetBSD compatibilitymagenbluten1-1/+1
2020-06-16Add $bin.link_member() functionBoris Kolpackov5-32/+138
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-16Move common functionality from cc to binBoris Kolpackov6-49/+265
2020-06-12Make order of imports stable in saved host build configurationBoris Kolpackov1-0/+2
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 Kolpackov2-2/+2
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-04-11Pass LC_ALL=C when extracting locale-dependent information in bin module on ↵Karen Arutyunov1-9/+50
POSIX
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-20Generate common .pc file in addition to static/staged when installing lib{}Boris Kolpackov1-1/+1
The common .pc file is produced by ignoring any static/shared-specific poptions and splitting loptions/libs into Libs/Libs.private. It is "best effort", in a sense that it's not guaranteed to be sufficient in all cases, but it will probably cover the majority of cases, even on Windows, thanks to automatic dllimport'ing of functions.
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 Kolpackov3-8/+52
2020-02-07Drop copyright notice from source codeKaren Arutyunov11-11/+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 Kolpackov2-3/+11
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-19Recognize various LLD drivers as well as LLVM lib and rcBoris Kolpackov2-24/+94
2019-10-16Try to find MSVC installation for absolute cl.exe pathsBoris Kolpackov1-1/+1
Without this extra logic recursive invocation of the build system (e.g., in tests) will fail to obtain the full environment.
generated by cgit v1.1 at 2024-04-29 23:46:38 +0000