Re: Setting rpath on llvmjit.so?

On Thu, Apr 26, 2018 at 01:16:09PM -0600, Jason Petersen wrote: > So the tooling around people using it is there and it’s used by some > very large and mature projects covering a variety of domains: I don’t > know if it’s “poorly supported” (the documentation leaves something to > be desired), but

Re: Setting rpath on llvmjit.so?

> On Apr 18, 2018, at 8:57 AM, Tom Lane wrote: > > I'm wondering whether that will result in expending a lot of effort to move > from a poorly-supported build system to a different poorly-supported build > system. I’m not sure whether the former is autoconf/make or cmake,

Re: Setting rpath on llvmjit.so?

I talked about autoconf build system, /tools/msvc it's extra home build system. On Thu, 19 Apr 2018, 00:58 Andres Freund, wrote: > On 2018-04-18 15:54:59 +, Yuriy Zhuravlev wrote: > > Current autoconf system not working on Windows at all, what we talk > about? > > We

Re: Setting rpath on llvmjit.so?

> > I also politely decline the offer to be forced to use XCode on mac. Why? We supporting MSVC and not nmake, what difference with xcode? Also, it's just extra benefit from cmake/meson.

Re: Setting rpath on llvmjit.so?

On 2018-04-18 15:54:59 +, Yuriy Zhuravlev wrote: > Current autoconf system not working on Windows at all, what we talk about? We generate windows project files. See src/tools/msvc/ - Andres

Re: Setting rpath on llvmjit.so?

Current autoconf system not working on Windows at all, what we talk about? On Wed, 18 Apr 2018, 23:57 Robert Haas, wrote: > On Tue, Apr 17, 2018 at 4:13 PM, Andres Freund wrote: > > I'd not advocate for this solely based on the age of autoconf. But

Re: Setting rpath on llvmjit.so?

On Tue, Apr 17, 2018 at 4:13 PM, Andres Freund wrote: > I'd not advocate for this solely based on the age of autoconf. But the > separate windows buildsystem which makes it very hard to build > extensions separately is a good reason on its own. As is the fact that > recursive

Re: Setting rpath on llvmjit.so?

On 4/17/18 16:14, Andres Freund wrote: > I still think cmake is the least unreasonable path going forward. I would rather try to make Meson work and if needed add features back into Meson. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote

Re: Setting rpath on llvmjit.so?

> Well, before it does everything, there's little point in reviewing > whether it's mergeable or not. For this significant case, it's not working as you expect. First, Postgres community should find consensus about migration to CMake (or alternative). Now, this project too huge to work on it

Re: Setting rpath on llvmjit.so?

Hi, On 2018-04-16 11:26:14 +0900, Yuriy Zhuravlev wrote: > My cmake branch still working and I supporting stable postgres releases: > https://github.com/stalkerg/postgres_cmake > Anyway, my branch exist, cmake working fine maybe without minor features > like generating documentation. > We can

Re: Setting rpath on llvmjit.so?

On 2018-04-17 15:56:14 -0400, Robert Haas wrote: > On Sat, Apr 14, 2018 at 5:13 PM, Andres Freund wrote: > > The half unmaintainedness of autoconf (no release in five years counts > > as that imo), sure makes it look like a good idea to move on to cmake or > > such at some

Re: Setting rpath on llvmjit.so?

Robert Haas writes: > ... But switching build systems > won't be frictionless, I think we have a nominee for Understatement of the Year. regards, tom lane

Re: Setting rpath on llvmjit.so?

On Sat, Apr 14, 2018 at 5:13 PM, Andres Freund wrote: > The half unmaintainedness of autoconf (no release in five years counts > as that imo), sure makes it look like a good idea to move on to cmake or > such at some point... I don't necessarily see that as a reason to move.

Re: Setting rpath on llvmjit.so?

2018-04-15 6:13 GMT+09:00 Andres Freund : > On 2018-04-14 17:10:21 -0400, Tom Lane wrote: > > Andres Freund writes: > > > On April 14, 2018 1:56:08 PM PDT, Tom Lane wrote: > > >> The project policy is to use exactly the GNU

Re: Setting rpath on llvmjit.so?

On 2018-04-14 17:10:21 -0400, Tom Lane wrote: > Andres Freund writes: > > On April 14, 2018 1:56:08 PM PDT, Tom Lane wrote: > >> The project policy is to use exactly the GNU distribution of autoconf. > > > Fwiw, I see one copyright year related diff with

Re: Setting rpath on llvmjit.so?

Andres Freund writes: > On April 14, 2018 1:56:08 PM PDT, Tom Lane wrote: >> The project policy is to use exactly the GNU distribution of autoconf. > Fwiw, I see one copyright year related diff with unmodified upstream autoconf. Really? Where did you

Re: Setting rpath on llvmjit.so?

On April 14, 2018 1:56:08 PM PDT, Tom Lane wrote: >Andres Freund writes: >> On 2018-04-14 12:32:35 -0700, Jeff Davis wrote: >>> PS: I also noticed that a autoconf run on master generates some >diffs >>> in configure. > >> I only see one copyright year

Re: Setting rpath on llvmjit.so?

Andres Freund writes: > On 2018-04-14 12:32:35 -0700, Jeff Davis wrote: >> PS: I also noticed that a autoconf run on master generates some diffs >> in configure. > I only see one copyright year related diff. Perhaps you're using a > patched distribution autoconf? The project

Re: Setting rpath on llvmjit.so?

Hi, On 2018-04-14 12:32:35 -0700, Jeff Davis wrote: > Currently, we don't set rpath for llvmjit.so to include `llvm-config -- > libdir`. That means you need to keep LD_LIBRARY_PATH set properly to > use any non-system installation of LLVM. Or pass in the appropriate flags to configure. My