[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