[LLVMdev] Long-Term Support for LLVM Projects Extension to Build System?

[mats petersson]

On 19 June 2015 at 15:57, Mehdi Amini <mehdi.amini at apple.com> wrote:

> Hi,
>
> If you just want to *link* to LLVM, it is not clear to me why you are not
> just relying on LLVM being built separately and have your project CMake
> pointing to the llvm build directory and using llvm-config to populate the
> linker argument?
>
> Best,
> —
> Mehdi
>

This is what I do in my Pascal compiler project. It may not be the perfect
solution, but I have not found any HUGE drawback yet.

--
Mats

>
> On Jun 19, 2015, at 7:38 AM, John Criswell <jtcriswel at gmail.com> wrote:
>
>  Dear All,
>
> Thanks for the feedback.
>
> To clarify, this is for LLVM-related projects that are linking against the
> LLVM libraries.
>
> The feature for keeping our source code in arbitrary locations isn't
> something we need.  If we can just drop our source code into llvm/projects
> (or some other designated LLVM subdirectory) and write LLVM-esque CMake
> files, that should be enough for projects that don't need to patch the
> existing LLVM tools.
>
> Regards,
>
> John Criswell
>
>
> On 6/18/15 9:06 PM, Chandler Carruth wrote:
>
>  On Thu, Jun 18, 2015 at 5:50 PM Hal Finkel <hfinkel at anl.gov> wrote:
>
>> This is also related to the metapoint that the cmake build system doesn't
>> glob for source files (or anything else), unlike the makefile build system.
>> This is understandable given the constraints, but we might want to restore
>> some of that functionality for the purpose of supporting out-of-tree
>> projects.
>>
>
>  I actually think these are completely separate. See below.
>
>
>>
>> What I mean specifically, is that, for example, we could have a
>> normally-empty directory tools/extensions, and tools/CMakeLists.txt could
>> glob for directories in tools/extensions and call
>> add_llvm_tool_subdirectory on all of them. It is true that you'd need to
>> re-run cmake whenever you added something there (we could have a README in
>> that directory to remind people of that), but that seems like a much
>> smaller price than having to maintain a patched version of the upstream
>> sources.
>>
>
>  We already do this in numerous places. See projects/CMakeLists.txt which
> does exactly this.
>
>  We don't automatically support external projects *in different
> locations* through globbing, but that's because that doesn't make any sense.
>
>  We can add globbing-based recursion to subproject CMake files anywhere
> it is useful.
>
>  There is no problem with globbing to add subdirectories IMO because
> subdirectories *with new CMake files* clearly have to be introduced and
> maintained at the points you run the 'cmake' tool. Only globbing for
> *source files* seems problematic to me at all.
>
>  -Chandler
>
>
> _______________________________________________
> LLVM Developers mailing listLLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> --
> John Criswell
> Assistant Professor
> Department of Computer Science, University of Rochesterhttp://www.cs.rochester.edu/u/criswell <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cs.rochester.edu_u_criswell&d=AwMD-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=4OeKj9B2JjfLUvqRMUSgftUrExBMlakSczNUQb3B5bU&s=D5Q1Ase7UHtkcpB-jO-JMfUNW5BFFSp0eCBvoOMEc70&e=>
>
>  _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150619/667fac8b/attachment.html>