aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/objc/CompilationSupport.java
Commit message (Collapse)AuthorAge
* C++: Separates adding sources and private headers to CcCompilationHelperGravatar plf2018-05-25
| | | | | | | | This is part of a chain of CLs that will pull initialization of CcCompilationContext from CcCompilationHelper. RELNOTES:none PiperOrigin-RevId: 198060027
* Extract logic for dealing with CROSSTOOL values and build variables into ↵Gravatar rosica2018-05-14
| | | | | | | separate class RELNOTES: None. PiperOrigin-RevId: 196517537
* C++: Renames CcCompilationContextInfo to CcCompilationContextGravatar plf2018-05-14
| | | | | | | Since it's not a provider, it doesn't need the Info suffix anymore. RELNOTES:none PiperOrigin-RevId: 196498526
* Remove cppConfiguration from LinkBuildVariablesGravatar hlopko2018-05-08
| | | | | | | | | This is to simplify the API that will eventually be exposed to Skylark. Working towards #4571. RELNOTES: None. PiperOrigin-RevId: 195785588
* Rename LinkStaticness to LinkingMode and unify with the other LinkingMode.Gravatar hlopko2018-05-07
| | | | | RELNOTES: None. PiperOrigin-RevId: 195777400
* Change action construction to use built-in param file support.Gravatar tomlu2018-04-27
| | | | | | | | | | | We want to be able to control how and when param files are used, and manual construction of param files prevents this. It should also be less code overall. For this CL, when param files are used is unchanged, their format and encoding is unchanged. The flag name is also unchanged, except in some cases it was changed from (eg.) "--flagfile foo" to "--flagfile=foo". However, the name of the param file is now derived from the primary output of the action (instead of manually controlled). RELNOTES: None PiperOrigin-RevId: 194607698
* Remove unused method.Gravatar jcater2018-04-26
| | | | PiperOrigin-RevId: 194430205
* SpawnAction.setShellCommand: expect shell pathGravatar laszlocsomor2018-04-23
| | | | | | | | | | | | | | | | | | | | | | | SpawnAction.setShellCommand(String) now expects the shell interpreter's path as an argument. This change enables two things: - rules can report an error if the shell is missing - SpawnAction no longer has to know about a default shell The new ShToolchain class will later also be responsible for retrieving the active shell toolchain (added in https://github.com/bazelbuild/bazel/commit/81ed3add408adb20bddbc3ba1818c65806738dc5). This change brings Bazel closer to not depend on the shell unless it has to (e.g. to run shell scripts). See https://github.com/bazelbuild/bazel/issues/4319 RELNOTES: none PiperOrigin-RevId: 193885943
* Thread more information through CcToolchainProvider for ↵Gravatar hlopko2018-04-20
| | | | | | | | | | CcCommon.configureFeatures The goal is to enable creation of feature configuration without the rule context. This will enable us to have cleaner API for this in Skylark. RELNOTES: None PiperOrigin-RevId: 193630386
* C++: Rename CcCompilationInfo to CcCompilationContextInfo.Gravatar plf2018-04-03
| | | | | | | | | This is done so that the name CcCompilationInfo can be used for the C++ provider that will wrap all providers for compilation, similar to JavaInfo in Java. RELNOTES:none PiperOrigin-RevId: 191445120
* ObjcLibrary.java: Use objectFilesCollector to get object filesGravatar pcloudy2018-03-28
| | | | | | | This can avoid passing targetBuilder to CompilationSupport.java RELNOTES: None PiperOrigin-RevId: 190743994
* Avoid using ObjectFilePathHelper in CompilationSupport.javaGravatar pcloudy2018-03-27
| | | | | RELNOTES: None. PiperOrigin-RevId: 190591828
* Shorten object file pathGravatar pcloudy2018-03-23
| | | | | | | | | | | | | | | | | | | | | | | Closes #4781. Fix https://github.com/bazelbuild/bazel/issues/4149 RELNOTES: Users can now pass --experimental_shortened_obj_file_path=true to have a shorter object file path, the object file paths (and all other related paths) will be constructed as following: If there's no two or more source files with the same base name: <bazel-bin>/<target_package_path>/_objs/<target_name>/<source_base_name>.<extension> otherwise: <bazel-bin>/<target_package_path>/_objs/<target_name>/N/<source_base_name>.<extension> N = the file?s order among the source files with the same basename, starts from 0. Examples: 1. Output names for ["lib1/foo.cc", "lib2/bar.cc"] are ["foo", "bar"] 2. Output names for ["foo.cc", "bar.cc", "foo.cpp", "lib/foo.cc"] are ["0/foo", "bar", "1/foo", "2/foo"] The default value of --experimental_shortened_obj_file_path option is false, but we plan to flip it to true and eventually remove this option. You shouldn't depend on the format of generated object file path, but if you do and this change breaks you, please use --experimental_shortened_obj_file_path=false to work around it. PiperOrigin-RevId: 190214375
* Move enabling of coverage related features to CcCommonGravatar Googler2018-02-23
| | | | | | | | Move dealing with coverage related features from CppConfiguration.configurationEnabledFeatures to CcCommon.configureFeatures. Remove configurationEnabledFeatures. RELNOTES: None. PiperOrigin-RevId: 186744803
* C++: Renames CppCompilationContext to CcCompilationInfoGravatar plf2018-02-21
| | | | | | | This is in preparation for migrating to the new way of specifying providers as described in[] RELNOTES:none PiperOrigin-RevId: 186436462
* Move CommandLine, CommandLineItem, and ParamFileInfo from ↵Gravatar tomlu2018-02-15
| | | | | | | | | lib.analysis.actions -> lib.actions. These are fundamental types that want to sit alongside types like Spawn. RELNOTES: None PiperOrigin-RevId: 185887971
* Add a CODEC for CppCompileAction.Gravatar cpeyser2018-02-14
| | | | PiperOrigin-RevId: 185733313
* Introduce -c source_file -o output_file build variablesGravatar hlopko2018-02-08
| | | | | | | | | | | | | | Prior to this cl CompileCommandLine would (almost) unconditionally emit -c and -o flags. This cl removes this logic and relies on crosstool to emit these flags. This is another small step towards platform independent C++ rules. Memory use is not affected, since the build variables used by this cl are already exposed, this cl just forces crosstools to use it. Encore of https://github.com/bazelbuild/bazel/commit/f26e8694ae78599b3e2004e3360eaf3443fa53a6. RELNOTES: None. PiperOrigin-RevId: 184981106
* C++: Split C++ library into two classes, compilation and linkingGravatar plf2018-02-08
| | | | | | | These will be separate calls in the Skylark API. RELNOTES:none PiperOrigin-RevId: 184961734
* Remove ios_test from Bazel. ios_test is an old rule and this removal is part ↵Gravatar kaipi2018-01-25
| | | | | | of the final steps of the migration process into Skylark. If you were using ios_test, please take a look at ios_unit_test provided by the github.com/bazelbuild/rules_apple project. PiperOrigin-RevId: 183251623
* Inline rarely used PathFragment methods that do not deserve to be on a core ↵Gravatar tomlu2018-01-19
| | | | | | path class. PiperOrigin-RevId: 182526427
* C++: Only call link() in cc_binary when linkCompileOutputSeparately is true.Gravatar plf2018-01-12
| | | | | | | | | Also rename setLinkType() to setStaticLinkType() in CcLibraryHelper to make it clear that we are setting the specific linking type for the static library. This is an improved version of https://github.com/bazelbuild/bazel/commit/a705eaa9225ff8a03975c8cb49faa6b2899e398d which was rolled back due to a previous conflicting CL causing problems in the nightly. RELNOTES:none PiperOrigin-RevId: 181746447
* Automated rollback of commit c166cd99ce9f72eed522e78d63c93ff410b6dc18.Gravatar plf2018-01-11
| | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** This was missing adding LTO files in the cc_embed_data rule. Fixed and added test. *** Original change description *** Automated rollback of commit 67330ad52391ad6562d439f77cc5133a0ea4247d. *** Reason for rollback *** Breaks nightly: b/71790513 *** Original change description *** C++ refactoring: Separate compilation and linking calls to CcLibraryHelper RELNOTES:none PiperOrigin-RevId: 181613477
* Automated rollback of commit 67330ad52391ad6562d439f77cc5133a0ea4247d.Gravatar plf2018-01-10
| | | | | | | | | | | | | *** Reason for rollback *** Breaks nightly: b/71790513 *** Original change description *** C++ refactoring: Separate compilation and linking calls to CcLibraryHelper RELNOTES:none PiperOrigin-RevId: 181457811
* C++ refactoring: Separate compilation and linking calls to CcLibraryHelperGravatar plf2018-01-08
| | | | | RELNOTES:none PiperOrigin-RevId: 181169134
* Remove CppConfiguration#supportsFission and #useFission. To do this, we:Gravatar cpeyser2017-12-20
| | | | | | | | | | | | (1) Remove configuration-level warnings arising from fission. (2) Move the setting of the "per_object_debug_info" feature from the configuration to FeatureConfiguration construction in the analysis phase. (3) Access the c++ toolchain in java_binary to decide on stripping. In order to migrate the c++ rules to platform-based toolchain resolution, we must remove all toolchain information from CppConfiguration. PiperOrigin-RevId: 179682420
* Remove FeatureSpecification, use plain sets insteadGravatar hlopko2017-12-19
| | | | | RELNOTES: None. PiperOrigin-RevId: 179534164
* Preemptively add deps back for Objective-C compilation after it was removed inGravatar plf2017-12-18
| | | | | | | https://github.com/bazelbuild/bazel/commit/d6ac11dab81ec40e9adc717575904574c6c9dc48. RELNOTES:none PiperOrigin-RevId: 179401717
* Remove source specific build variables from C++ API.Gravatar plf2017-12-15
| | | | | | | | | | | The only use case was for Objective-C rules so that different set of sources specified in the same rule could be compiled with either ARC or no ARC. To replace source specific build variables, we call into CcLibraryHelper twice for each set of sources. This has led to separating the building of compilation providers and outputs from those related to linking. In the case of Objective-C, the compilation outputs are merged and then passed to a single invocation of linking in CcLibraryHelper. In a later CL, the distinction between compilation and linking will be refined by separating them in different classes. RELNOTES:none PiperOrigin-RevId: 179167102
* Eliminate STATIC_FRAMEWORK_DIR as a separate field of ObjcProvider.Gravatar cparsons2017-11-28
| | | | | | | | | Infer those values from STATIC_FRAMEWORK_FILE. This correctly dedupes static frameworks between an app and its dylibs. RELNOTES: None. PiperOrigin-RevId: 177214770
* Remove dead code from CompilationSupportGravatar cparsons2017-11-28
| | | | | RELNOTES: None. PiperOrigin-RevId: 177165649
* Allow an action_config to be activated by default.Gravatar cpeyser2017-11-13
| | | | PiperOrigin-RevId: 175531318
* Remove CppConfiguration#getFeatures in favor ofGravatar cpeyser2017-11-06
| | | | | | CcToolchainProvider#getFeatures. PiperOrigin-RevId: 174492427
* Remove legacy implementation of objc compilation/archiving/linking.Gravatar cpeyser2017-11-06
| | | | PiperOrigin-RevId: 174481563
* Automated rollback of commit 5d42ae10195cd1acb9612df3a3d520f09b0c3e39.Gravatar cpeyser2017-11-03
| | | | | | | | | | | | | *** Reason for rollback *** Breaks alphago targets. *** Original change description *** Remove CppConfiguration#getFeatures in favor of CcToolchainProvider#getFeatures. PiperOrigin-RevId: 174373331
* Remove CppConfiguration#getFeatures in favor ofGravatar cpeyser2017-10-30
| | | | | | CcToolchainProvider#getFeatures. PiperOrigin-RevId: 173702792
* Export apple_host_system_env and target_apple_env through apple_common (as ↵Gravatar lberki2017-10-16
| | | | | | | | | opposed to only through ctx.fragments.apple) Progress towards #3424. RELNOTES: None. PiperOrigin-RevId: 172299240
* Move RuleConfiguredTarget to lib.analysis.configuredtargets.Gravatar gregce2017-09-19
| | | | | | This is a trivial change with a large file footprint. PiperOrigin-RevId: 169169864
* Automatic code cleanup.Gravatar cushon2017-09-15
| | | | PiperOrigin-RevId: 168802886
* Support multiple command lines / params files in SpawnAction.Gravatar tomlu2017-09-15
| | | | | | This is necessary for the upcoming Skylark implementation of param files. PiperOrigin-RevId: 168744486
* Inline CustomCommandLine methods that can be expressed using VectorArg.Gravatar tomlu2017-09-12
| | | | | | This whole CL was done using IDE refactoring tools and should be safe. PiperOrigin-RevId: 168275575
* Automated rollback of commit fc41c430e4de4594a1d699f573d191cbad52a2fb.Gravatar plf2017-09-01
| | | | PiperOrigin-RevId: 167154793
* Move ObjcProvider FLAG into a new provider type (TransitiveSourcesProvider) ↵Gravatar cpeyser2017-08-30
| | | | | | that is accessible to the c++ rules. PiperOrigin-RevId: 166934390
* Automated rollback of commit 1af9b1e2238c3b43a2b66233495ecf7b6ef4dcab.Gravatar Googler2017-08-25
| | | | | | | | | | | | *** Reason for rollback *** Reason for previous rollback was identified as being a memory regression causing some cases to hit java heap limit. Proposal is to increase java heap limit to compensate and just go with the original change. *** Original change description *** Automated rollback of commit 6cfffdf37e11018c7e6e2cabc90440d6d29c819b. PiperOrigin-RevId: 166426608
* Improve CustomCommandLine interface.Gravatar tomlu2017-08-22
| | | | | | | | | | | | | | | | In converting SpawnAction.Builder (multi-thousand line CL) users directly to CustomCommandLine I didn't like the resulting loss of readability, and the methods didn't feel very discoverable. Unless it's very convenient and readable to use CustomCommandLine, people will resort to non-memory efficient patterns by default. I'm holding that CL for this, which should offer a nicer interface. This CL removes VectorArg from the API contact surface area, instead creating 64 overloads for every valid combination of parameters. Pretty sad, but the methods dispatch straight to internal helper methods so it's mostly boilerplate to the tune of +400 LOC. Other changes: * Change ImmutableCollection -> Collection and copy the args directly into the internal args vector. Saves on collection object overhead and saves users from having to create immutable copies. * Change some names, notably add -> addAll for collection methods * Create additional missing overloads * Fix JavaDoc RELNOTES: None PiperOrigin-RevId: 165943879
* Add more type safety to CustomCommandLine.Gravatar tomlu2017-08-16
| | | | | | | | | | | | Allowing add(Object) is too loose and can easily lead to programmer mistakes. Because of type erasure, we can't use the same overload name for (eg.) add(NestedSet<String>) and add(NestedSet<Artifact>). The API is overhauled to use the same terms everywhere, eg. "add", "addPaths", "addExecPaths". This is similar to how it used to be a few CLs ago. The API is overhauled to make sure it's consistent for all types. While tedious, the facade methods immediately dispatch to internal helpers, so implementation wise it's not too heavy. While large, this CL is almost entirely an automated refactor. PiperOrigin-RevId: 165358287
* Add @CompileTimeConstant annotations to CustomCommandLine.Gravatar tomlu2017-08-16
| | | | | | | | | This enforces certain memory-efficient patterns. For deliberate use of dynamic strings, explicitly named overloads are introduced, with javadoc that guides the programmer into making the right choice. This CL is a memory no-op on benchmarks, but it tries to prevent backslide by making sure programmers make conscious choices when they construct their command lines. RELNOTES: None PiperOrigin-RevId: 165185997
* Inline @Deprecated methods in CustomCommandLine.Gravatar tomlu2017-08-11
| | | | | | | | | Apart from updating CustomCommandLineTest this CL is entirely automated. We also sneak in a rename of addFormat -> addFormatted. RELNOTES: None PiperOrigin-RevId: 164870140
* Move core test classes to lib.analysis.testGravatar ulfjack2017-08-11
| | | | | | | | These are depended upon by analysis code, so need to live in the same library as lib.analysis. Moving them here makes it possible to split the build-base library into separate libraries for analysis, execution, and rules. PiperOrigin-RevId: 164847161
* Improve CustomCommandLine.Gravatar tomlu2017-08-10
| | | | | | | | | | | | | Instead of having custom ArgvFragments for every combination of desired things, we make a combined "interpreter" of argvs. This saves memory and simplifies things as we do not have to allocate a strategy instance per call to args (instead pushing a single shared instance, followed by the args). The generic interpreter does have a lot of branching compared to the bespoke implementations, but because the branch is always the same for long stretches the branch predictor should easily be able to handle it with minimal overhead (~1 cycle per branch IIRC). This CL also elevates that we either want a NestedSet or an ImmutableCollection to the surface of the API, so consumers understand the cost when they call it with a non-immutable collection. Most of the changes in clients is due to this. To cut down on CL churn, @Deprecated forwarding methods are added to CustomCommandLine. These will be removed in a separate CL using IDE inlining. RELNOTES: None PiperOrigin-RevId: 164725370
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-09 19:03:08 +0000