[PATCH] D24167: Moving to GitHub - Unified Proposal

[Duncan P. N. Exon Smith via llvm-commits]

> On 2016-Oct-12, at 15:20, Mehdi Amini <mehdi.amini at apple.com> wrote:
> 
>> 
>> 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?

I refuse to answer ;).  Maybe there are more scripts than this?  Maybe it has options?  I don't know, and it doesn't matter, as long as there are sane defaults for new users.

I have no interest in designing this right now, I don't know if we'll care enough to do it, and I don't think it's relevant to the proposal or the decisions ahead.

I have problems with your straw man:
- CMake -D options are not discoverable, so this is a high barrier to entry.
- It seems to rely on a top-level CMakeLists.txt, which hasn't been discussed directly as a possibility (only top-level sub-projects).
- There have to be other ways to glue things together anyway, so that separate repos continue to work properly (since they won't be checking out your top-level non-sub-project).

Leave it in if you want, but IMO it invites bike-shedding on something that everything thinks is solvable.

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