mats petersson
2015-Jun-19 15:07 UTC
[LLVMdev] Long-Term Support for LLVM Projects Extension to Build System?
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>
Chris Bieneman
2015-Jun-19 16:59 UTC
[LLVMdev] Long-Term Support for LLVM Projects Extension to Build System?
Supporting out-of-tree tools without needing to modify the in-tree CMake code is something I’ve been thinking about adding to the CMake build system (we already support this for projects, but I was thinking about doing it differently for tools). I’ve written loads of internal tools, and it is obnoxious to have out-of-tree modifications to the CMakeLists files. The idea I had for tools was to do something similar to the globing Chandler posted out in projects/CMakeLists.txt, but to treat globed external projects more like how we treat Polly; off by default and requiring a setting to enable them. -Chris> On Jun 19, 2015, at 8:07 AM, mats petersson <mats at planetcatfish.com> wrote: > > > > On 19 June 2015 at 15:57, Mehdi Amini <mehdi.amini at apple.com <mailto: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 <mailto: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 <mailto: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 list >>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >> >> >> -- >> John Criswell >> Assistant Professor >> Department of Computer Science, University of Rochester >> http://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 <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <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/3fa13fa5/attachment.html>
Chris Bieneman
2015-Jun-22 20:03 UTC
[LLVMdev] Long-Term Support for LLVM Projects Extension to Build System?
I was looking this morning at supporting out-of-tree tools, and it is actually already there today. If you add a directory under tools that has a CMakeLists.txt file it will get picked up and added as long as LLVM_INCLUDE_TOOLS isn’t set to “bootstrap-only” (which is a dirty hack that needs to die). This happens through a call to add_llvm_implicit_external_projects(). There are some more bells and whistles I’d like to add in this area, but it is functional today. -Chris> On Jun 19, 2015, at 9:59 AM, Chris Bieneman <beanz at apple.com> wrote: > > Supporting out-of-tree tools without needing to modify the in-tree CMake code is something I’ve been thinking about adding to the CMake build system (we already support this for projects, but I was thinking about doing it differently for tools). I’ve written loads of internal tools, and it is obnoxious to have out-of-tree modifications to the CMakeLists files. > > The idea I had for tools was to do something similar to the globing Chandler posted out in projects/CMakeLists.txt, but to treat globed external projects more like how we treat Polly; off by default and requiring a setting to enable them. > > -Chris > >> On Jun 19, 2015, at 8:07 AM, mats petersson <mats at planetcatfish.com <mailto:mats at planetcatfish.com>> wrote: >> >> >> >> On 19 June 2015 at 15:57, Mehdi Amini <mehdi.amini at apple.com <mailto: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 <mailto: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 <mailto: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 list >>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >>> >>> >>> -- >>> John Criswell >>> Assistant Professor >>> Department of Computer Science, University of Rochester >>> http://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 <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <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/20150622/b27f2775/attachment.html>