Re: Is a modern build system acceptable for older platforms

> > Arguing with people and telling them that they're wrong or (as you appear > to be doing) that they're old and out of touch isn't going to make them any > more likely to want to use your code. > You are totally wrong, I didn't it, especial called somebody "old". Perhaps you think like this

Re: Is a modern build system acceptable for older platforms

> > Is it worth spending thousands of person-hours converting what we have > into something different that happens to be de rigeur, and (especially) > using up many hours of our precious core developer time while they learn > the new methods, while not actually gaining functionality? Also,

Re: Is a modern build system acceptable for older platforms

First, I apologize if my words hurt someone. I didn't want this. Second, I totally agree with Andrew. > He's also right that the build system is among the > least of our problems in making newcomers feel comfortable. > This what I wanted to say. Not big technical difference between build systems

Re: Is a modern build system acceptable for older platforms

> > It is correct that Gmail is incapable of this in the web browser. Many > other email systems can though, and Gmail still speaks imap so you can use > those if you prefer. > Mail programs outside web browser not popular anymore and this standalone programs became very slow to grow (for example

Re: Is a modern build system acceptable for older platforms

> > It's more than just a bunch of conservative dinosaurs not wanting to > change how they do anything, > I didn't talk that. It's that a change needs to offer really compelling benefits > Because of this benefits depend on your development style and your habits. For me for example, simple

Re: Is a modern build system acceptable for older platforms

пн, 28 мая 2018 г. в 16:42, Pierre Ducroquet <p.p...@pinaraf.info>: > On Monday, May 28, 2018 4:37:06 AM CEST Yuriy Zhuravlev wrote: > > > Can't see getting rid of those entirely. None of the github style > > > platforms copes with reasonable complex discussions.

Re: Is a modern build system acceptable for older platforms

> > Can't see getting rid of those entirely. None of the github style > platforms copes with reasonable complex discussions. I disagree. A good example of complex discussions on github is Rust language tracker for RFCs: https://github.com/rust-lang/rfcs/issues and one concrete example:

Re: Is a modern build system acceptable for older platforms

I suppose I can make summary after reading all this: 1. Any change in the development process will be possible if it will be convenient for each key developers personally only. (development process include build system) 2. Currently, almost all key developers use Unix like systems, they have

Re: Is a modern build system acceptable for older platforms

> > Sorry, but comparing lines at that state is just bullshit. I totally disagree, proportions will be same in any case. Most of the comments of converted tests are missing. > Add 100-500 lines? ok. You detect like a third of the things that the old configure > detected. > I tried to use

Re: Is a modern build system acceptable for older platforms

2018-05-03 9:32 GMT+09:00 Andres Freund <and...@anarazel.de>: > On 2018-05-03 09:29:32 +0900, Yuriy Zhuravlev wrote: > > > > > > I don't think that unsubstantiated hyperbole is the right way to > > > approach the task of convincing the community to

Re: Is a modern build system acceptable for older platforms

> > I don't think that unsubstantiated hyperbole is the right way to > approach the task of convincing the community to adopt the approach > you prefer. It's not a hyperbole it's fact and I even talked about it on conference. You should just compare all my cmake files with Makefile+.in+.m4 (and

Re: Is a modern build system acceptable for older platforms

After small check I found next: we need gcc 4.8 anyway for libjit and it means RHEL 7 and newer: https://access.redhat.com/solutions/19458 because 4.8 needed to build LLVM.

Re: Is a modern build system acceptable for older platforms

> > No tons of hacks. > And functions too https://bitbucket.org/adunstan/pg-closed-ranges/raw/0475b50ff793ce876a78c96d72903c9793a98fc1/cmake/FindPostgreSQL.cmake I mean things like HAVE_LONG_LONG_INT you can't figure out on "configure" stage without parsing config.h in CMake. Also, maybe I am

Re: Is a modern build system acceptable for older platforms

> Indeed. It's possibly today to use CMake without a huge amount of difficulty to build extensions out of tree against MSVC-built postgres. How? All builds what I saw was with tons of hacks. On windows, Postgres can build against Mingw, many versions of MSVC and etc Also, you can build Postgres

Re: Is a modern build system acceptable for older platforms

> > That indeed would be an improvement, but maybe we could fix that specific > pain point without having to throw away twenty years worth of work? Indeed! Only a few thousands of lines of code can generate the whole you manually wrote, it's the perfect result! re-invention of portability hacks

Re: Is a modern build system acceptable for older platforms

Hello Geoff! About cmake: 1. You can still use the binary build for your system. 2. You can still build Postgres from source and with old gcc, you need only install cmake (it's very easy) Only most modern versions of CMake depend on modern gcc. I have good experience with old Solaris and AIX. (I

Re: Issues while building PG in MS Windows, using MSYS2 and MinGW-w64

If you have time, can you check CMake version? https://github.com/stalkerg/postgres_cmake During Mingw installation you can choose a version, it can be more MSVC like or more Unix, probably Postgres have a problem with one of mingw type. So I unpacked the source tarball within the shell

Re: obsoleting plpython2u and defaulting plpythonu to plpython3u

And Gentoo too. > PEP 394 points out that some distros (at least Arch) have already switched >

Re: Support Python 3 tests under MSVC

Interesting, this working fine more than year with CMake build version. On Tue, 1 May 2018, 04:53 Andrew Dunstan, wrote: > > Here are a couple of patches, one for master and one for the back > branches from 9.5 to 10 to allow testing of plpython3 and associated >

Re: Is a modern build system acceptable for older platforms

> > this is not about having a working build environment, it is about having > a fully working and correct source tarball before distributing it as a > new release. Sorry, I did not understand correctly it before. I suppose it's not big problem especial if you have CI and tests farm. And anyway

Re: Is a modern build system acceptable for older platforms

> > Which is nice > OK Again, nice > Yeah, that's nice I already use CMake I'd do it, personally > I suppose we have no one silver bullet reason to change autoconf+make to CMake but it's cumulative impression. Also, I suppose this thread started to resolve at least one small question.

Re: Is a modern build system acceptable for older platforms

> > Makefiles generated by automake are more feature rich in general, > which is understandable as its the only backend it has to support. The main problem here - Postrges do not use automake at all! Postgres it's autoconf + handmade GNU Make files + perl script for generating old MSVC project

Re: Is a modern build system acceptable for older platforms

> (2) it might make things easier on Windows, > which could be a sufficiently good reason but I don't think I've seen > anyone explain exactly how much easier it will make things and in what > ways. > 1. You can remove tools/msvc folder because all your build rules will be universal. (cmake

Re: Is a modern build system acceptable for older platforms

> > My gut reaction to Catalin's list is that requiring C+11 is a pretty > darn high bar to clear for older platforms. > It's only for latest version and we can support version 3.9 with C++98 I think at least 5 years. 3.9.6 was realease in November 10, 2017 . That's a pretty big shift from the

Re: Is a modern build system acceptable for older platforms

About CMake: We can use 3.9 version very well, it has all features for us, at least for my postgres_cmake branch and I have the experience to introduce features to cmake special for postgres build. Also, cmake very easily build even for Solaris or AIX (on my webpage I have examples to build

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, <and...@anarazel.de> wrote: > On 2018-04-18 15:54:59 +0000, Yuriy Zhuravlev wrote: > > Current autoconf system not working on Windows at all, what we talk

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?

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?

> 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?

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