On Wed, 30 May 2018 at 00:51, Yuriy Zhuravlev wrote:
> You are totally wrong, I didn't it, especial called somebody "old".
>
Then I apologise for misunderstanding your intention. Language/culture
barrier perhaps?
Geoff
>
>
> 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
>
> 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,
On Mon, 28 May 2018 at 03:30, Yuriy Zhuravlev wrote:
> 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,
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
On Mon, May 28, 2018 at 4:23 PM, Bruce Momjian wrote:
> On Mon, May 28, 2018 at 11:16:08AM +0200, Magnus Hagander wrote:
>> I would argue the exact opposite - mail is a lot more flexible than using
>> github issues and that's one of the most important reasons I prefer it.
>>
>> (and there are of
On Mon, May 28, 2018 at 11:16:08AM +0200, Magnus Hagander wrote:
> I would argue the exact opposite - mail is a lot more flexible than using
> github issues and that's one of the most important reasons I prefer it.
>
> (and there are of course many ways to tag and categorize your email, many
>
> 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
On Mon, May 28, 2018, 10:03 Yuriy Zhuravlev wrote:
> пн, 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
>> > >
пн, 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.
> >
> > I disagree. A good
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.
>
> I disagree. A good example of complex discussions on github is Rust
> language tracker for RFCs:
>
>
> 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:
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
On Thu, May 17, 2018 at 10:42:00PM -0700, Andres Freund wrote:
> > We also have what seems like half an OS worth of tooling to support our
> > shared-nothing-by-default multi-processing model. Custom spinlocks, our
> > LWLocks, our latches, signal based IPC + ProcSignal signal multiplexing,
> >
2018-05-18 5:50 GMT+02:00 Craig Ringer :
> On 18 May 2018 at 11:10, Andres Freund wrote:
>
>>
>>
>> On May 17, 2018 7:44:44 PM PDT, Bruce Momjian wrote:
>> >On Thu, May 3, 2018 at 12:32:39AM +0200, Catalin Iacob wrote:
>> >> I do
On 18 May 2018 at 11:10, Andres Freund wrote:
>
>
> On May 17, 2018 7:44:44 PM PDT, Bruce Momjian wrote:
> >On Thu, May 3, 2018 at 12:32:39AM +0200, Catalin Iacob wrote:
> >> I do have a real concern about the long term attractiveness of the
> >> project
On May 17, 2018 7:44:44 PM PDT, Bruce Momjian wrote:
>On Thu, May 3, 2018 at 12:32:39AM +0200, Catalin Iacob wrote:
>> I do have a real concern about the long term attractiveness of the
>> project to new developers, especially younger ones as time passes.
>> It's not a secret
On Thu, May 3, 2018 at 12:32:39AM +0200, Catalin Iacob wrote:
> I do have a real concern about the long term attractiveness of the
> project to new developers, especially younger ones as time passes.
> It's not a secret that people will just avoid creaky old projects, and
> for Postgres old out
Hello, Yuriy.
You wrote:
YZ> (2) it might make things easier on Windows,
YZ> which could be a sufficiently good reason but I don't think I've seen
YZ> anyone explain exactly how much easier it will make things and in what
YZ> ways.
YZ> 1. You can remove tools/msvc folder because all
>
> 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
On 2018-05-03 09:42:49 +0900, Yuriy Zhuravlev wrote:
> 2018-05-03 9:32 GMT+09:00 Andres Freund :
> > Given that you don't have feature parity this just seems like trolling.
> >
>
> I have. I have some lacks with .po generation and documentation but all!
> other features same,
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
> > > you prefer.
> >
> >
> >
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
> > you prefer.
>
>
> It's not a hyperbole it's fact and I even talked about it on conference.
>
>
> 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
On Wed, May 2, 2018 at 5:44 PM, Robert Haas wrote:
> 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. I don't see that any compelling evidence has been
> presented that a
Andres Freund writes:
> Now you could argue that we could just rewrite to non-recursive
> make. But that'd be nearly as much work as migrating to another
> buildsystem.
I'm sure it'd be a significant amount of work ... but it wouldn't require
redesigning any configuration or
On 2018-05-02 23:43:50 +0200, Hartmut Holzgraefe wrote:
> On 02.05.2018 17:44, Robert Haas wrote:
> > But having parallel make work better and more efficiently
> > and with fewer hard-to-diagnose failure modes would definitely be
> > nice.
>
> that's especially a thing I haven't seen in "our"
On 02.05.2018 17:44, Robert Haas wrote:
But having parallel make work better and more efficiently
and with fewer hard-to-diagnose failure modes would definitely be
nice.
that's especially a thing I haven't seen in "our" environment,
this was an area where autotools and cmake didn't really
On Tue, May 1, 2018 at 8:12 PM, Yuriy Zhuravlev wrote:
>> 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
On 02.05.2018 16:22, Tom Lane wrote:
(-D? really?)
it's worse ... "cmake -L" only produces a alphabetically sorted list
of known -D settings, just listing the names without description.
That's so far behind from what
./configure --help
produces.
(And don't get me started on cmake-gui.
Geoff Winkless writes:
> Being blunt, unless I've missed the point all the arguments I've read so
> far for cmake seem to be advantages for the developers, not the users. As
> developers who put in your time you are of course entitled to make your
> lives easier but I'm just
On Wed, 2 May 2018 at 00:57, Yuriy Zhuravlev wrote:
> 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
On May 1, 2018 9:26:27 PM PDT, Yuriy Zhuravlev wrote:
>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.
We don't use libjit. As for the llvm stuff
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
On Tue, May 1, 2018 at 8:20 PM, Yuriy Zhuravlev wrote:
>> 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.
There is a simple
> 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
>
> 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
On Tue, May 1, 2018 at 12:46 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2018-05-01 12:19:28 -0400, Robert Haas wrote:
>>> I found your brain dump an interesting read, and I have to say that it
>>> leaves me rather uninspired about making a change.
Andres Freund writes:
> On 2018-05-01 12:19:28 -0400, Robert Haas wrote:
>> I found your brain dump an interesting read, and I have to say that it
>> leaves me rather uninspired about making a change. It sounds to me
>> like if we change, some things will be better and others
On Tue, May 1, 2018 at 12:31 PM, Andres Freund wrote:
> How is being able to build extensions on windows reasonably not an
> improvement? It's really hard to build pgxs like stuff on windows right
> now. Also not having to maintain a fair amount of visual studio project
>
I'd like to add my 2c that, as a user who has to support postgres running
on some fairly old systems, changing to a modern build mechanism (with all
the resultant dependency hell that it would likely introduce) would be
likely to cause me much grief.
At the moment I can still log in to the old RH
On 2018-05-01 12:19:28 -0400, Robert Haas wrote:
> On Fri, Apr 27, 2018 at 5:46 AM, Hartmut Holzgraefe
> wrote:
> > I could probably continue with this brain dump forever, ...
>
> I found your brain dump an interesting read, and I have to say that it
> leaves me
On Fri, Apr 27, 2018 at 5:46 AM, Hartmut Holzgraefe
wrote:
> I could probably continue with this brain dump forever, ...
I found your brain dump an interesting read, and I have to say that it
leaves me rather uninspired about making a change. It sounds to me
like
>
> 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
>
> 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.
On 28.04.2018 05:27, Yuriy Zhuravlev wrote:
"make distcheck"
CMake have no this bad concept, in my opinion, if you want to make the
project you should have a full build environment. (but I don't want to
argue about it here)
this is not about having a working build environment, it is
>
> 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
On 27.04.2018 10:45, Mark Kirkwood wrote:
I note that Mysql (yeah I know, we don't love 'em greatly, but their
product niche is similar to ours) and Ceph (ok it is a distributed
storage system but still a highly popular open src product) have
switched to using cmake (relatively) recently.
On 27/04/18 19:10, Yuriy Zhuravlev wrote:
1. You can remove tools/msvc folder because all your build rules will
be universal. (cmake build now have much fewer lines of code)
2. You can forget about terminal in Windows (for windows guys it's
important)
3. You can normally check environment on
> (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
On Thu, Apr 19, 2018 at 10:16 AM, Tom Lane wrote:
> The other side of that argument is that allowing a build system we haven't
> even adopted yet to dictate which platforms we can support is definitely
> letting the tail wag the dog.
>
> My gut reaction to Catalin's list is
>
> 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
>
> The above is all about getting the build system to work at all. If that
> isn't a showstopper there's a subsequent discussion to be had about older
> platforms where one could get the build system to work but convenient
> packages are missing. For example not even RHEL7 has any Python3
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
There have been several discussions of replacing PG's autoconf +
src/tools/msvc system. The last example is happening now at the bottom of
the Setting rpath on llvmjit.so thread.
I see potentially big advantages to moving but also to PG's conservative
approach that keeps it running on edge and
58 matches
Mail list logo