[PATCH] D24167: Moving to GitHub - Unified Proposal

[Mehdi Amini via llvm-commits]

> On Oct 12, 2016, at 3:08 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> 
> 
>> 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

Does it include libcxx? compiler-rt? lld?

> $ ../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

Having an example of “what it could look like” seems better to me than hand-wavy “we’ll make sure something works”.

> , but your straw-man looks error-prone since someone has to remember command-line options

Looks in line with -DLLVM_TARGETS_TO_BUILD and other options though. 
Or even with the current system (every other week someone email llvm-dev with an issue before realizing that he checked out compiler-rt in llvm/tools instead of llvm/projects).


> , instead of just finding a path on the filesystem.
> 
> Either way, not a big deal.