[PATCH] D24167: Moving to GitHub - Unified Proposal

Duncan P. N. Exon Smith via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 12 15:08:07 PDT 2016


> On 2016-Oct-12, at 14:54, Mehdi Amini <mehdi.amini at apple.com> wrote:
> 
>>> +Building a single sub-project
>>> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> +
>>> +Nobody will be forced to build unnecessary projects.  The exact structure
>>> +is TBD, but making it trivial to configure builds for a single sub-project
>>> +(or a subset of sub-projects) is a hard requirement.
>>> +
>>> +As an example, it could look like the following::
>>> +
>>> +  mkdir build && cd build
>>> +  # Configure only LLVM (default)
>>> +  cmake path/to/monorepo
>>> +  # Configure LLVM and lld
>>> +  cmake path/to/monorepo -DLLVM_ENABLE_PROJECTS=lld
>>> +  # Configure Error: lldb project requires also clang
>> 
>> ^ why wouldn't this pull in Clang?
> 
> I don’t feel strongly about that.
> This is a straw man, just to show that we can perform some early sanity checks.
> Would we pull clang as if it was specified, or without enabling the clang binaries targets (assuming LLDB only needs libclang). I.e. with this config `ninja clang` would yield "error: unknown target ‘clang’”?
> 
> 
>>> +  cmake path/to/monorepo -DLLVM_ENABLE_PROJECTS=lldb
>> 
>> I think you should leave this out since it's not carefully designed, and I'm
>> hoping we can make it even better using CMake caches (or something similar).
> 
> Not sure how you can get it better than “I supply my list of projects”?
> I mean having shortcut like “ALL” or “CLANG_TOOLCHAIN” may be useful as well, but that’s only a plus.

Not saying this is the best solution (maintainability or whatever), but as another strawman, it's definitely easier to have:

$ ../path/to/llvm-projects/clang/build.py
$ ../path/to/llvm-projects/lldb/build.py
$ ../path/to/llvm-projects/llvm/build.py

or

$ ../path/to/llvm-projects/build-clang.py
$ ../path/to/llvm-projects/build-lldb.py
$ ../path/to/llvm-projects/build-llvm.py

I assume something similar that could be fairly easily achieved with CMake caches too (and maybe if we had a python script, it would wrap a CMake cache invocation).  The cache itself would maybe be:

$ cmake -C ../path/to/llvm-projects/clang/caches/build-clang.cmake
...

I'd still rather leave out the straw-man, but your straw-man looks error-prone since someone has to remember command-line options, instead of just finding a path on the filesystem.

Either way, not a big deal.


More information about the llvm-commits mailing list