r255799 - [CMake] Make CLANG_BOOTSTRAP_TARGETS overridable

Author: cbieneman Date: Wed Dec 16 12:45:53 2015 New Revision: 255799 URL: http://llvm.org/viewvc/llvm-project?rev=255799&view=rev Log: [CMake] Make CLANG_BOOTSTRAP_TARGETS overridable This allows exposing a custom list of targets from the next stage build up. Modified: cfe/trunk/CMakeLists.

r255801 - [CMake] If you're building compiler-rt, the bootstrap build should depend on it.

Author: cbieneman Date: Wed Dec 16 12:49:12 2015 New Revision: 255801 URL: http://llvm.org/viewvc/llvm-project?rev=255801&view=rev Log: [CMake] If you're building compiler-rt, the bootstrap build should depend on it. Adding optional dependency for the bootstrap targets on compiler-rt. Modified:

r255813 - [CMake] Name the bootstrap stages stage[0-9]

Author: cbieneman Date: Wed Dec 16 14:17:07 2015 New Revision: 255813 URL: http://llvm.org/viewvc/llvm-project?rev=255813&view=rev Log: [CMake] Name the bootstrap stages stage[0-9] When you start chaining bootstrap stages the CMake-generated targets get unwieldy. This change supports naming the

[PATCH] D15584: [CMake] Support a simple case for bootstrap builds to generate PGO data

beanz created this revision. beanz added reviewers: bogner, silvas, chandlerc. beanz added a subscriber: cfe-commits. This patch adds support for the clang multi-stage bootstrapping to support PGO profdata generation, and can build a 2 or 3 stage compiler. With this patch applied you can configu

Re: [PATCH] D15584: [CMake] Support a simple case for bootstrap builds to generate PGO data

> On Dec 17, 2015, at 11:37 AM, Justin Bogner wrote: > > Chris Bieneman mailto:be...@apple.com>> writes: >> beanz created this revision. >> beanz added reviewers: bogner, silvas, chandlerc. >> beanz added a subscriber: cfe-commits. >> >> This

Re: [PATCH] D15584: [CMake] Support a simple case for bootstrap builds to generate PGO data

beanz updated this revision to Diff 43177. beanz added a comment. Updates based on bogner's feedback. - Target stages are now stage2-instrumented and stage2 instead of stage2 and stage3. - Renamed PGO-stage1.cmake to PGO.cmake http://reviews.llvm.org/D15584 Files: CMakeLists.txt cmake/cac

Re: [PATCH] D15584: [CMake] Support a simple case for bootstrap builds to generate PGO data

beanz updated this revision to Diff 43183. beanz added a comment. Updating to fix a bug in my CMake regex handling that caused the targets to not be mapped up correctly. http://reviews.llvm.org/D15584 Files: CMakeLists.txt cmake/caches/PGO-stage2.cmake cmake/caches/PGO-stage3.cmake cma

Re: [PATCH] D15584: [CMake] Support a simple case for bootstrap builds to generate PGO data

beanz updated this revision to Diff 43192. beanz added a comment. One more dependency hookup fix, this one makes it so that stage2 doesn't depend on the stage2-instrumented compiler-rt, and avoids building it when you invoke the 'stage2' target. http://reviews.llvm.org/D15584 Files: CMakeLi

r256057 - [CMake] PGO training data

Author: cbieneman Date: Fri Dec 18 17:00:57 2015 New Revision: 256057 URL: http://llvm.org/viewvc/llvm-project?rev=256057&view=rev Log: [CMake] PGO training data Adding in a few more lit substitutions for cc1 and the test exec path. Modified: cfe/trunk/utils/perf-training/lit.cfg Modified:

r256069 - [CMake] Support a simple case for bootstrap builds to generate PGO data

Author: cbieneman Date: Fri Dec 18 18:56:10 2015 New Revision: 256069 URL: http://llvm.org/viewvc/llvm-project?rev=256069&view=rev Log: [CMake] Support a simple case for bootstrap builds to generate PGO data Summary: This patch adds support for the clang multi-stage bootstrapping to support PGO

r256070 - [CMake] Fixing a typo in a flag

Author: cbieneman Date: Fri Dec 18 18:56:12 2015 New Revision: 256070 URL: http://llvm.org/viewvc/llvm-project?rev=256070&view=rev Log: [CMake] Fixing a typo in a flag Turns out cc1's flag has 1 - not 2... Modified: cfe/trunk/utils/perf-training/lit.cfg Modified: cfe/trunk/utils/perf-traini

r256088 - Revert "[CMake] Support a simple case for bootstrap builds to generate PGO data"

Author: cbieneman Date: Fri Dec 18 23:47:50 2015 New Revision: 256088 URL: http://llvm.org/viewvc/llvm-project?rev=256088&view=rev Log: Revert "[CMake] Support a simple case for bootstrap builds to generate PGO data" This reverts commit r256069, which was an unintentional tag along on another com

[clang] a1155f6 - [NFC] Clang-format const array declarations

Author: Chris Bieneman Date: 2024-02-15T13:16:21-06:00 New Revision: a1155f68f5d5c7013ca1deb312a2e1e4f71ef544 URL: https://github.com/llvm/llvm-project/commit/a1155f68f5d5c7013ca1deb312a2e1e4f71ef544 DIFF: https://github.com/llvm/llvm-project/commit/a1155f68f5d5c7013ca1deb312a2e1e4f71ef544

[clang] 0065161 - Remove assert introduced in #71098

Author: Chris Bieneman Date: 2024-02-15T18:56:35-06:00 New Revision: 0065161c720c37e8ab545979aed6a03d944a3176 URL: https://github.com/llvm/llvm-project/commit/0065161c720c37e8ab545979aed6a03d944a3176 DIFF: https://github.com/llvm/llvm-project/commit/0065161c720c37e8ab545979aed6a03d944a3176

[clang] f119a4f - [HLSL] Fix broken spir-v test

Author: Chris Bieneman Date: 2024-04-02T15:53:17-05:00 New Revision: f119a4ffb885ed588c46de1d51f4185572142ca2 URL: https://github.com/llvm/llvm-project/commit/f119a4ffb885ed588c46de1d51f4185572142ca2 DIFF: https://github.com/llvm/llvm-project/commit/f119a4ffb885ed588c46de1d51f4185572142ca2

[clang] 5b95931 - [NFC] Delete unintentionally added file

Author: Chris Bieneman Date: 2024-04-03T11:24:48-05:00 New Revision: 5b959310b0fae723bd119ed8815bf1cb1a8c67d4 URL: https://github.com/llvm/llvm-project/commit/5b959310b0fae723bd119ed8815bf1cb1a8c67d4 DIFF: https://github.com/llvm/llvm-project/commit/5b959310b0fae723bd119ed8815bf1cb1a8c67d4

[clang] 9d3437f - [ADT] [NFC] Add StringRef::detectEOL

Author: Chris Bieneman Date: 2022-01-21T09:47:02-06:00 New Revision: 9d3437fbf3419502351d41ff9e28f06b0c3f06e8 URL: https://github.com/llvm/llvm-project/commit/9d3437fbf3419502351d41ff9e28f06b0c3f06e8 DIFF: https://github.com/llvm/llvm-project/commit/9d3437fbf3419502351d41ff9e28f06b0c3f06e8

[clang] 121b225 - AddGlobalAnnotations for function with or without function body.

Author: Chris Bieneman Date: 2021-10-11T14:50:34-05:00 New Revision: 121b2252de0eed68f2ddf5f09e924a6c35423d47 URL: https://github.com/llvm/llvm-project/commit/121b2252de0eed68f2ddf5f09e924a6c35423d47 DIFF: https://github.com/llvm/llvm-project/commit/121b2252de0eed68f2ddf5f09e924a6c35423d47

[clang] 43de869 - Implement #pragma clang restrict_expansion

Author: Chris Bieneman Date: 2021-08-23T09:46:38-07:00 New Revision: 43de869d77f77eedf9f8760f94940a249d2b5a41 URL: https://github.com/llvm/llvm-project/commit/43de869d77f77eedf9f8760f94940a249d2b5a41 DIFF: https://github.com/llvm/llvm-project/commit/43de869d77f77eedf9f8760f94940a249d2b5a41

[clang] 50581ef - [NFC] Fix warning in recent commit

Author: Chris Bieneman Date: 2025-02-15T14:19:31-06:00 New Revision: 50581ef1ee45815b9230043319de5ae93680d4ad URL: https://github.com/llvm/llvm-project/commit/50581ef1ee45815b9230043319de5ae93680d4ad DIFF: https://github.com/llvm/llvm-project/commit

[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

beanz added a subscriber: jfb. beanz added a comment. Adding @jfb since this is his domain now too. Repository: rC Clang https://reviews.llvm.org/D45639 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman

[PATCH] D49486: [cfe][CMake] Export the clang resource directory

beanz added a comment. I’m not opposed to this patch, but is there a real need for this? Have you considered just running clang with the `-print-resource-dir` flag? https://reviews.llvm.org/D49486 ___ cfe-commits mailing list cfe-commits@lists.llvm

[PATCH] D49486: [cfe][CMake] Export the clang resource directory

beanz added a comment. Please check and see if that works for you. In general I prefer to avoid adding new features that aren't used in-tree unless it is unavoidable or would be difficult to work around out-of-tree. This one seems pretty straightforward to me. https://reviews.llvm.org/D49486

[PATCH] D50618: Refactor Darwin driver to refer to runtimes by component

beanz created this revision. beanz added reviewers: phosek, bruno, arphaman. In r335809, Petr Hosek lays out support for what he calls the multiarch runtimes layout. This new way of laying out the directories for runtime libraries is workable for all platforms. Petr did some of the common infrastr

[PATCH] D50755: [Driver] -print-target-triple and -print-effective-triple options

beanz accepted this revision. beanz added a comment. This revision is now accepted and ready to land. lgtm Repository: rC Clang https://reviews.llvm.org/D50755 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/

[PATCH] D50547: [Driver] Use normalized triples for multiarch runtime path

beanz accepted this revision. beanz added a comment. This revision is now accepted and ready to land. LGTM! Repository: rC Clang https://reviews.llvm.org/D50547 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin

[PATCH] D50547: [Driver] Use normalized triples for multiarch runtime path

beanz added a comment. Just want to bring an IRC conversation that I had with @phosek into the proper code review. This patch is great as-is, but if we want to extend this to Darwin there are some problems because of how Darwin handles triples. Specifically Darwin has multiple potentially vali

[PATCH] D50547: [Driver] Use normalized triples for multiarch runtime path

beanz accepted this revision. beanz added a comment. LGTM as-is Comment at: clang/lib/Driver/ToolChain.cpp:372 - const Driver &D = getDriver(); - SmallString<128> P(D.ResourceDir); - llvm::sys::path::append(P, D.getTargetTriple(), "lib"); - if (getVFS().exists(P)) { + fo

[PATCH] D31363: [libc++] Remove cmake glob for source files

beanz added a comment. Building libcxx without LLVM's CMake modules is very important, not just to Apple. This is how several open source distributions work, and it would be a huge disservice to break this. Same is true for compiler-rt, libcxxabi, libunwind, etc. Historically we've been drawin

[PATCH] D51440: [ToolChains] Link to compiler-rt with -L + -l when possible

beanz added a reviewer: phosek. beanz added a subscriber: phosek. beanz added a comment. Looping in @phosek. Repository: rC Clang https://reviews.llvm.org/D51440 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bi

[PATCH] D51440: [ToolChains] Link to compiler-rt with -L + -l when possible

beanz added a subscriber: dexonsmith. beanz added a comment. Unfortunately I can't make this kind of policy decision about whether or not this would be acceptable for Darwin. That would probably need to be @dexonsmith. Repository: rC Clang https://reviews.llvm.org/D51440 _

[PATCH] D51645: [CMake] Don't use -rtlib=compiler-rt with -nodefaultlibs.

beanz accepted this revision. beanz added a comment. This revision is now accepted and ready to land. LGTM. Repository: rUNW libunwind https://reviews.llvm.org/D51645 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/c

[PATCH] D51986: Fixes for `LLVM_LINK_LLVM_DYLIB` && Polly.

beanz added a comment. I don’t think this is the right solution. The build system knows what components are in the dylib and should remove them from the list of libraries linked individually. You should be able to make Polly behave like an LLVM component, then tools don’t need to care if the dy

[PATCH] D51986: Fixes for `LLVM_LINK_LLVM_DYLIB` && Polly.

beanz added a comment. After line 18 in this file you could do something like: if(WITH_POLLY) list(APPEND LLVM_LINK_COMPONENTS Polly) endif() Then you can get rid of the `target_link_libraries` call. Repository: rC Clang https://reviews.llvm.org/D51986 _

[PATCH] D51986: Fixes for `LLVM_LINK_LLVM_DYLIB` && Polly.

beanz added a comment. I agree that changing the naming scheme probably makes sense, but I also think that you can probably make a fairly well contained change to the LLVM CMake module that maps components to libnames to special case Polly and make this all work. I’d really like to see us avoi

[PATCH] D32604: CMakeLists: Deprecate using llvm-config to find llvm install path

beanz accepted this revision. beanz added a comment. This revision is now accepted and ready to land. LGTM! https://reviews.llvm.org/D32604 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co

[PATCH] D32595: CMakeLists: Don't set LLVM_MAIN_SRC_DIR when building stand-alone clang

beanz added a comment. Is this really something we should be supporting? Building and testing clang with potentially out-of-sync lit or gtest seems undesirable to me. It is worth noting that we do have mods to gtest, so supporting any standard distribution of it seems like a not great idea. The

[PATCH] D32817: [CMake] Build runtimes for Fuchsia targets

beanz accepted this revision. beanz added a comment. This revision is now accepted and ready to land. This all looks great. I'm really excited to have such a complete toolchain build example in-tree. Thank you! Repository: rL LLVM https://reviews.llvm.org/D32817 __

[PATCH] D32595: CMakeLists: Don't set LLVM_MAIN_SRC_DIR when building stand-alone clang

beanz accepted this revision. beanz added a comment. This revision is now accepted and ready to land. Ah. I see what you're saying. I was thinking of the mismatch in a different way, but your solution makes sense. LGTM. https://reviews.llvm.org/D32595

[PATCH] D41660: [cmake] Add new linux toolchain file

beanz added a comment. You should split the CMake cache file you created into two files, (1) a CMake Cache to manage the build configuration and (2) a tool chain file for targeting Linux. As @semeenai pointed out we absolutly want the behavior of the toolchain file being loaded multiple times.

[PATCH] D41706: [CMake] Install resource files into a share/ directory

beanz added a reviewer: kubamracek. beanz added a subscriber: kubamracek. beanz added a comment. For reference this relates to https://reviews.llvm.org/D41673. Looking in @kubamracek. Repository: rC Clang https://reviews.llvm.org/D41706 ___ cfe-

[PATCH] D41807: [cmake] Delete redundant install command for clang-refactor.

beanz accepted this revision. beanz added a comment. This revision is now accepted and ready to land. LGTM Repository: rC Clang https://reviews.llvm.org/D41807 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/

[PATCH] D47355: [CMake] Allow specifying extra dependencies of bootstrap stage

beanz accepted this revision. beanz added a comment. This revision is now accepted and ready to land. I prefer `DEPS` to `COMPONENTS` because I've tried to explicitly use the term components to mean targets that have paired build and install targets. Otherwise looks good. Repository: rC Clan

[PATCH] D60926: [CMake] Replace the sanitizer support in runtimes build with multilib

beanz accepted this revision. beanz added a comment. This revision is now accepted and ready to land. I really like this. Using `+` to add variants seems much widely useful. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60926/new/ https://reviews.llvm.org/D60926 _

[PATCH] D57521: [CMake] External compiler-rt-configure requires LLVMTestingSupport when including tests

beanz added a reviewer: phosek. beanz added a subscriber: phosek. beanz added a comment. Herald added a project: clang. @phosek, does LLVM’s runtime directory do this correctly? At some point we should try and deprecate and remove this option in favor of the LLVM directory because the LLVM appro

[PATCH] D35133: [cmake] Use new GetSVN.cmake SOURCE_DIRS parameter

beanz accepted this revision. beanz added a comment. This revision is now accepted and ready to land. Since the dependent patch landed, this LGTM too. https://reviews.llvm.org/D35133 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lis

[PATCH] D62693: Support codesigning bundles and forcing

beanz created this revision. beanz added reviewers: jkorous, bogner. Herald added subscribers: kadircet, arphaman, dexonsmith, ilya-biryukov, mgorny. Herald added projects: clang, LLVM. Clangd's framework is assembled by copying binaries from the lib and bin directories into a bundle shape. This

[PATCH] D62279: Use LTO capable linker

beanz accepted this revision. beanz added a comment. This revision is now accepted and ready to land. This is good to land. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62279/new/ https://reviews.llvm.org/D62279

[PATCH] D61446: Generalize the pass registration mechanism used by Polly to any third-party tool

beanz added a comment. I have a thought for how we can make the CMake interface for this better. Instead of `LLVM_EXTENSIONS` being a global property if it were a pre-defined list like `LLVM_ALL_PROJECTS`, then the `LLVM_LINK__INTO_TOOLS` variables can be generated by LLVM's configuration inste

[PATCH] D61446: Generalize the pass registration mechanism used by Polly to any third-party tool

beanz added inline comments. Comment at: llvm/cmake/modules/AddLLVM.cmake:820 + +set(LLVM_ALL_EXTENSION_TARGETS clang;bugpoint;opt) +foreach(tool ${LLVM_ALL_EXTENSION_TARGETS}) I don't think we should hard code this list. It would be much

[PATCH] D61446: Generalize the pass registration mechanism used by Polly to any third-party tool

beanz added inline comments. Comment at: llvm/cmake/modules/AddLLVM.cmake:812 +# llvm::PassPluginLibraryInfo ${entry_point}(); +add_custom_target(LLVM_PLUGINS) # target used to hold global properties referencable from generator-expression +function(register_llvm_extension

[PATCH] D64580: cmake: Add INSTALL_WITH_TOOLCHAIN option to add_*_library macros

beanz accepted this revision. beanz added a comment. This revision is now accepted and ready to land. LGTM. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64580/new/ https://reviews.llvm.org/D64580 ___

[PATCH] D64579: [clang-shlib] Fix clang-shlib for PRIVATE dependencies

beanz accepted this revision. beanz added a comment. Yea, this makes sense even if it is a bit sad. We do use the `--whole-archive` approach for `libLLVM`, and it works. I was hoping to avoid it here in part to free up the ability to link `libclang_shared` before or in parallel to archiving the

[PATCH] D64582: cmake: Fix install of libclang_shared.so when LLVM_INSTALL_TOOLCHAIN_ONLY=ON

beanz accepted this revision. beanz added a comment. LGTM. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64582/new/ https://reviews.llvm.org/D64582 ___ cfe-commits mailing list cfe-commits@lists.llvm.o

[PATCH] D64278: Rename libclang_shared to libclang-cpp

beanz accepted this revision. beanz added a comment. This revision is now accepted and ready to land. This is fine with me. I have no real attachment to the name. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64278/new/ https://reviews.llvm.org/D64278

[PATCH] D65270: [CMake] Fix source path generation for install in multi-config (MSBuild)

beanz requested changes to this revision. beanz added inline comments. This revision now requires changes to proceed. Comment at: clang/lib/Headers/CMakeLists.txt:190 +if(CMAKE_CONFIGURATION_TYPES) + string(REPLACE "${CMAKE_CFG_INTDIR}" "$" output_dir "${output_dir}")

[PATCH] D66068: cmake: Make building clang-shlib optional

beanz added a comment. I generally am not a fan of adding more and more options. As long as you're not linking the library it won't be generated by any of the check targets. With the llvm dylib we've had many issues over the years where changes to LLVM break building the dylib and many develope

[PATCH] D66068: cmake: Make building clang-shlib optional

beanz added a comment. I think you and I disagree here. General developer workflows don't need to include building `all` for every minor change. In my normal workflow I just re-run `check-llvm` or `check-clang` over and over again, only building the `all` target before I post a patch. With that

[PATCH] D66068: cmake: Make building clang-shlib optional

beanz added a comment. In D66068#1626266 , @jvesely wrote: > That's your workflow. I need to run 'make install' because the modifications > are used by an external project. If there's an option to skip shlib during > 'make install' I'd be happy to use it

[PATCH] D66068: cmake: Make building clang-shlib optional

beanz added a comment. I want to dissect this a bit. In D66068#1627451 , @E5ten wrote: > I am in favour of adding a user-facing option to disable generating this > duplicate library for users that don't need it Why do you call this duplicate? It is uni

[PATCH] D66068: cmake: Make building clang-shlib optional

beanz added a reviewer: compnerd. beanz added a comment. In D66068#1628617 , @jvesely wrote: > It duplicates functionality provided by separate/component libraries. The component libraries can't be used the way this can, and this is intended as an insta

[PATCH] D63503: cmake: Add CLANG_LINK_CLANG_DYLIB option

beanz added a comment. One comment inline. Otherwise LGTM. Comment at: clang/CMakeLists.txt:327 +set(CLANG_LINK_CLANG_DYLIB ${LLVM_LINK_LLVM_DYLIB} CACHE BOOL +"Link tools against libclang_shared.so") + We should generate a config error if `LLVM_LINK_LLVM_D

[PATCH] D61804: Support building shared and static libraries simultaneously

beanz added a comment. I question the general utility of this patch, and I don't really think this does anything we want the build system doing. If you specify `STATIC` and `SHARED` to `llvm_add_library` it creates the shared library target as the one that everything links against, which is ex

[PATCH] D61804: Support building shared and static libraries simultaneously

beanz added a comment. As an additional note, Arch linux should not be building clang with `BUILD_SHARED_LIBS` nor should it be distributing those ,so files. That isn't a supported configuration for Clang deployment. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://re

[PATCH] D61804: Support building shared and static libraries simultaneously

beanz added a comment. In D61804#1499275 , @winksaville wrote: > When you say you don't think the build system should do this, what do you > mean? `llvm_add_library` supports both, because there are places where we consciously choose to build both. Tha

[PATCH] D61804: Support building shared and static libraries simultaneously

beanz added a comment. My change should not have decreased build time from trunk, nor should it have reduced the number of build steps. That patch should generate lib/libClang_shared.so, which will export the C++ API. libClang is unchanged since changing it would break existing clients of the l

[PATCH] D61909: Add Clang shared library with C++ exports

beanz created this revision. beanz added reviewers: tstellar, winksaville. Herald added a subscriber: mgorny. Herald added a project: clang. This patch adds a libClang_shared library on *nix systems which exports the entire C++ API. In order to support this on Windows we should really refactor l

[PATCH] D61804: Support building shared and static libraries simultaneously

beanz added a comment. @winksaville that was my bad. I left off the new files in the commit because I forgot `git-diff` doesn't grab untracked files... I've uploaded the patch as a D61909 . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION http

[PATCH] D61909: Add Clang shared library with C++ exports

beanz updated this revision to Diff 199508. beanz added a comment. Changed to lowercase 'c' to match other clang libraries. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61909/new/ https://reviews.llvm.org/D61909 Files: clang/cmake/modules/AddCl

[PATCH] D61909: Add Clang shared library with C++ exports

beanz added a comment. @winksaville whether or not PIC is required for shared libraries varies by platform. These days LLVM defaults to -fPIC, and I'm not sure we actually support running LLVM without -fPIC on systems that require shared libraries to be PIC. Repository: rG LLVM Github Monor

[PATCH] D61909: Add Clang shared library with C++ exports

beanz added a comment. In D61909#1502446 , @winksaville wrote: > Questions: > > - Should we only build `libclang_shared.so` if `LLVM_BUILD_LLVM_DYLIB` is ON? `LLVM_BUILD_LLVM_DYLIB` is actually not the important option to think about because it has no i

[PATCH] D61909: Add Clang shared library with C++ exports

beanz added a comment. In D61909#1503433 , @winksaville wrote: > IMHO "`BUILD_CLANG_DYLIB`" is needed. As you have it now libclang_shared.so > is always builds on UNIX systems, which I believe means that all linux > distros would have both increasing the

[PATCH] D61909: Add Clang shared library with C++ exports

beanz added a comment. In D61909#1503642 , @winksaville wrote: > Sorry, maybe I didn't make myself clear. I understood you fine. I don't think you understand the guidance for building distributions of LLVM. Distributions only get libclang_shared if the

[PATCH] D61909: Add Clang shared library with C++ exports

beanz added a comment. There is a simpler example distribution configuration, but sadly there isn't documentation. That is something I can fix. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61909/new/ https://reviews.llvm.org/D61909 ___

[PATCH] D61909: Add Clang shared library with C++ exports

beanz added a comment. I should note, this and many more aspects of the build system were topics I discussed in a talk at the 2016 LLVM Dev meeting when we switched off autoconf: https://www.youtube.com/watch?v=StF77Cx7pz8 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https

[PATCH] D61909: Add Clang shared library with C++ exports

beanz added a comment. In D61909#1505083 , @winksaville wrote: > Please add documentation if you want people to use it :) I won't disagree that it should be documented, and I already started. I do want to point out though that your motivation starting t

[PATCH] D61909: Add Clang shared library with C++ exports

beanz added a comment. I will land this patch as-is today. I'll try and get a doc patch out for review today or tomorrow. @winksaville, I'm going to add a section to the document about building LLVM as a shared library for inclusion with tool distributions. That still shouldn't be done with `BU

[PATCH] D61909: Add Clang shared library with C++ exports

beanz added a comment. I would leave it out of any distribution (at least for now). Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61909/new/ https://reviews.llvm.org/D61909 ___ cfe-commits mailing list cfe-commits@li

[PATCH] D61909: Add Clang shared library with C++ exports

beanz added a comment. @sylvestre.ledru, I’ve added you on D62040 , which is an attempt to document best practices for generating releases. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61909/new/ https://reviews.llvm.org/D61909

[PATCH] D61909: Add Clang shared library with C++ exports

beanz added a comment. @E5ten, I see what is going on. Give me 30 minutes and I’ll have a fix pushed. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61909/new/ https://reviews.llvm.org/D61909 ___ cfe-commits mailing l

[PATCH] D61909: Add Clang shared library with C++ exports

beanz added a comment. @E5ten, I just pushed r361271, which should resolve your issue. I have a better longer-term fix in mind that I'll put up for review this week. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61909/new/ https://reviews.llvm.org/D61909

[PATCH] D62215: Fixes to distribution example for X86_64 Arch Linux

beanz added a comment. Adding "libcxxabi" to `LLVM_ENABLE_RUNTIMES` is fine, but the other changes to the DistributionExample are only needed because you chose to use gold, which is a configuration-specific decision that is not representative of how most people will build, therefore it shouldn'

[PATCH] D61909: Add Clang shared library with C++ exports

beanz added a comment. In D61909#1510955 , @E5ten wrote: > @beanz Well I took libclang_shared as effectively an equivalent to the > libLLVM.so that's created with that dylib option, and when BUILD_SHARED_LIBS > is enabled that library is not created, in

[PATCH] D61909: Add Clang shared library with C++ exports

beanz added a comment. In D61909#1510975 , @E5ten wrote: > @beanz But if libclang_shared is intended to be a shippable binary and > BUILD_SHARED_LIBS is only intended to be an option used in developer builds, > and libclang_shared while not causing confl

[PATCH] D62215: Fixes to distribution example for X86_64 Arch Linux

beanz added a comment. In D62215#1512543 , @winksaville wrote: > With this error I guessed that I needed to build `LLVMgold.so`, but then I > also determined > I needed to link everything with `ld.gold` to complete the build process, > which is why I >

[PATCH] D62215: Fixes to distribution example for X86_64 Arch Linux

beanz added a comment. D62269 should fix the missing dependency on `gtest`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62215/new/ https://reviews.llvm.org/D62215 _

[PATCH] D62215: Fixes to distribution example for X86_64 Arch Linux

beanz added a comment. In D62215#1512849 , @winksaville wrote: > IIRC, on linux if LTO is ON I had to use `ld.gold` for both stage 1 and 2, > although that maybe > just the way it ended up and it wasn't necessary. But I'll test whatever you > come up wi

[PATCH] D62279: Use LTO capable linker

beanz added a comment. In D62279#1514046 , @winksaville wrote: > I've add gtest_main and gtest to CLANG_BOOTSTRAP_TARGETS as a guess, because > that's where check-all is defined: > ... > My guess is likely wrong, what do you advise? Are you still hav

[PATCH] D62279: Use LTO capable linker

beanz added a comment. In D62279#1514467 , @winksaville wrote: > Even with both gtest patches it still isn't working, `ninja check-all` is > failing as before :( I wouldn't expect your gtest patch to resolve the issue. The `CLANG_BOOTSTRAP_TARGETS` var

[PATCH] D62279: Use LTO capable linker

beanz added a comment. @winksaville I've figured out how to resolve the `gtest` issue, but unfortunately that isn't good enough to get the `check-runtimes` target working. A change went in back in February (rL353601 ), which breaks running compiler-rt's tests

[PATCH] D62343: [cmake] Remove old unused version of FindZ3.cmake from clang [NFC]

beanz accepted this revision. beanz added a comment. This revision is now accepted and ready to land. LGTM. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62343/new/ https://reviews.llvm.org/D62343 ___

[PATCH] D67321: Respect CLANG_LINK_CLANG_DYLIB=ON in libclang and c-index-test

beanz added a comment. @aaronpuchert sounds like a reasonable approach Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D67321/new/ https://reviews.llvm.org/D67321 ___ cfe-commits mailing list cfe-commits@

[PATCH] D67585: [clang] [cmake] Make building dylib optional

beanz requested changes to this revision. beanz added a comment. This revision now requires changes to proceed. Please no. You don’t need to build the library. ‘check-clang’ doesn’t depend on it, so it should not impact your build and test cycles. We want it included in the ‘all’ target for ever

[PATCH] D67585: [clang] [cmake] Make building dylib optional

beanz added a comment. In D67585#1670420 , @mgorny wrote: > Sure but I want to build-test practically everything else. I wouldn't mind if > this didn't basically kill my test system by resource exhaustion You can use the ‘LLVM_DISTRIBUTION_COMPONENTS’ o

[PATCH] D67585: [clang] [cmake] Make building dylib optional

beanz added a reviewer: compnerd. beanz added a comment. In D67585#1670433 , @mgorny wrote: > This is really much more work than disabling the one component I don't need > or care for, especially when I do shared lib build and therefore the > additional

[PATCH] D67585: [clang] [cmake] Make building dylib optional

beanz added a comment. In D67585#1670491 , @mgorny wrote: > But in that case, we should aim for consistency, i.e. remove the matching > option from LLVM. Yes! I want to do that too. After the mono-repo transition is finalized I think we need to invest

[PATCH] D68413: [clang] [cmake] Add distribution install targets for remaining components

beanz accepted this revision. beanz added a comment. This revision is now accepted and ready to land. LGTM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68413/new/ https://reviews.llvm.org/D68413 ___ cfe-commits mailing list cfe-commits@lis

[PATCH] D68430: Don't use object libraries with Xcode

beanz added a comment. This has the side-effect of making `libclang_cpp` effectively empty when you build with Xcode. What exactly does Xcode do with `OBJECT` libraries? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68430/new/ https://reviews.llv

[PATCH] D68429: [clang] [cmake] Use add_clang_tool() to install all tools

beanz added a comment. Are these tools intended to be installed? I thought they were developer focused tools. I don't think we should make install targets for things that the project doesn't want to support publicly. This also changes the behavior of the `install` target to include these extra

[PATCH] D68430: Don't use object libraries with Xcode

beanz added a comment. In D68430#1693964 , @jordan_rose wrote: > I'm not quite sure //what// it's doing. The executable targets end up trying > to link against the static libraries anyway, which of course haven't been > built. It's possible that this is

<    1   2   3   4   5   6   7   8   9   10   >