>
> 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 beca
>
> 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, probab
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
>
> 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
>
> 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 CMake
пн, 28 мая 2018 г. в 16:42, Pierre Ducroquet :
> 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.
> >
> >
>
> 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: https://gi
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
strong
>
> 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 CMak
2018-05-03 9:32 GMT+09:00 Andres Freund :
> 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 adopt the approach
>
>
> 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 m
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.
>
> 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 wron
> 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 w
>
> 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
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 m
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 itself(u
And Gentoo too.
> PEP 394 points out that some distros (at least Arch) have already switched
>
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
> contrib modules when building wi
>
> 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 i
>
> 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.
>
> 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 fr
> (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 build
>
> 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 pr
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 postgre
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 +0000, Yuriy Zhuravlev wrote:
> > Current autoconf system not working on Windows at all, what we talk
> about?
>
&
>
> 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.
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 the
> > separate windows buildsystem which mak
> 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 wit
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 distribution of autoconf.
> >
> > > Fwiw, I see one copyright year relat
30 matches
Mail list logo
