llvm dev - Jul 2020 - Proposal for CIRCT incubator project

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/20200709/29da0022/attachment.html>

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/20200709/1b363317/attachment.html>

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>