[llvm-dev] Proposal for CIRCT incubator project

[Renato Golin via llvm-dev]

Hi Steve,

Thanks for the update! This will fix the ugliest hack I have on my build
script.

I know I wasn't doing the nicest thing, but it's nice to see that what I
needed wasn't that far away.

I'll update my scripts and get back to you.

Really appreciate, thanks!
Renato

On Fri, 10 Jul 2020, 07:59 Stephen Neuendorffer, <
stephen.neuendorffer at gmail.com> wrote:

> Renato,
>
> After looking at your testcase, it seems that you're trying to relocate a
> 'build' directory and are having to rewrite absolute paths in the build
> directory.
> Build directories are not really relocatable, partly because of absolute
> paths, and partly because of dealing with shared library rpaths IIRC.  I
> tried your testcase
> with an install directory and it seems to work (at least for the MLIR
> parts) even if the install directory is relocated. This is because a
> different set of cmake exports
> are generated for install directories.  Also note also that MLIR does
> install the .inc files generated by tablegen for this to work.
>
> Steve
>
>
> On Thu, Jul 9, 2020 at 7:51 AM Stephen Neuendorffer <
> stephen.neuendorffer at gmail.com> wrote:
>
>> Renato, I'm happy to kibitz on the build problems.  Cmake seems to be
>> working well at this point for us, but it took quite a bit to get there and
>> there are some pitfalls. I'm aware of some namespace issues in mlir, but
>> haven't gotten around to dealing with them.
>>
>> Steve
>>
>>
>> On Thu, Jul 9, 2020, 3:47 AM Renato Golin <rengolin at gmail.com> wrote:
>>
>>> On Wed, 8 Jul 2020 at 22:43, Chris Lattner <clattner at nondot.org> wrote:
>>> > I think that flang beat us to the punch as the first external MLIR
>>> user :-) but thank you for your support Renato!
>>>
>>> Ah, but Flang is in the monorepo and builds together with LLVM, while
>>> CIRCT (and my current project, Verona) "uses" MLIR/LLVM externally (as
>>> a submodule).
>>>
>>> There are a number of build issues in both LLVM and MLIR that make it
>>> awkward for projects in that category to use the LLVM libraries and
>>> having a project in the llvm group will give us an "official" reason
>>> to solve those problems more efficiently.
>>>
>>> I've been meaning to start a thread on that, but I need to collect all
>>> the build issues I had in an email so we can discuss them. Not for
>>> this thread, though. :)
>>>
>>> cheers,
>>> --renato
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200710/2bc47ac5/attachment-0001.html>