Re: [HACKERS] WIP: About CMake v2

On Wed, Feb 8, 2017 at 04:52:19PM -0500, Tom Lane wrote: > Peter Eisentraut writes: > > On 2/8/17 6:21 AM, Yuriy Zhuravlev wrote: > >> Support two build systems it's not big deal really. I have been working > >> on this past year without any big troubles. > >>

Re: [HACKERS] WIP: About CMake v2

On Mon, Feb 13, 2017 at 10:52 AM, Peter Eisentraut wrote: > People have all kinds of expectations on how the build system behaves. > It's not just ./configure; make; make install. All kinds of niche and > edge cases have evolved over the years. Variables you

Re: [HACKERS] WIP: About CMake v2

On 2/8/17 4:44 PM, Andres Freund wrote: >> Well, I find it a bit scary. If you do the big switch all at once, then >> you will have to dedicate the following 3 months to fixing complaints >> from developers and build farmers. > > That'll be the case just as well if we spread it out over two

Re: [HACKERS] WIP: About CMake v2

2017-02-12 20:55 GMT+03:00 Vladimir Rusinov : > Overall, when things go wrong debugging cmake requires cmake knowledge, > while autotools mostly require shell knowledge which is much more common > (again, for sysadmins/packagers). It's not really true because of CMake

Re: [HACKERS] WIP: About CMake v2

On Fri, Feb 10, 2017 at 5:07 PM, Robert Haas wrote: > But also, I'm not really sure whether this conversion makes sense. I > mean, any build system is going to require some work, and accordingly > our present build systems require some work. cmake will require >

Re: [HACKERS] WIP: About CMake v2

On 2017-02-10 10:22:34 -0800, Andres Freund wrote: > On 2017-02-10 12:07:15 -0500, Robert Haas wrote: > > But also, I'm not really sure whether this conversion makes sense. I > > mean, any build system is going to require some work, and accordingly > > our present build systems require some work.

Re: [HACKERS] WIP: About CMake v2

On 11 Feb. 2017 08:42, "Andrew Dunstan" wrote: On 02/10/2017 01:27 PM, Magnus Hagander wrote: > On Fri, Feb 10, 2017 at 6:07 PM, Robert Haas > wrote: > > On Mon, Jan 30, 2017 at 10:26 AM, Peter

Re: [HACKERS] WIP: About CMake v2

On 02/10/2017 01:27 PM, Magnus Hagander wrote: > On Fri, Feb 10, 2017 at 6:07 PM, Robert Haas > wrote: > > On Mon, Jan 30, 2017 at 10:26 AM, Peter Eisentraut >

Re: [HACKERS] WIP: About CMake v2

On Feb 10, 2017 19:41, "Andres Freund" wrote: On 2017-02-10 19:33:18 +0100, Magnus Hagander wrote: > I guess we wouldn't, but we'd still need the "replacement for autoconf" > part. So then we're back to maintaining multiple buildsystems. Hm? Do we really need that? Most of

Re: [HACKERS] WIP: About CMake v2

On 2017-02-10 19:33:18 +0100, Magnus Hagander wrote: > I guess we wouldn't, but we'd still need the "replacement for autoconf" > part. So then we're back to maintaining multiple buildsystems. Hm? Do we really need that? Most of the things in an extension you do *not* want to determine separately

Re: [HACKERS] WIP: About CMake v2

On 2017-02-10 20:31:12 +0200, Heikki Linnakangas wrote: > On 02/10/2017 08:27 PM, Magnus Hagander wrote: > > For me a killer feature would be if/when we can get to a point where we can > > have something pgxs-style on cmake that also works on windows. > > > > Our homemade Windows build system

Re: [HACKERS] WIP: About CMake v2

On Fri, Feb 10, 2017 at 7:31 PM, Heikki Linnakangas wrote: > On 02/10/2017 08:27 PM, Magnus Hagander wrote: > >> For me a killer feature would be if/when we can get to a point where we >> can >> have something pgxs-style on cmake that also works on windows. >> >> Our homemade

Re: [HACKERS] WIP: About CMake v2

On 2017-02-10 19:27:55 +0100, Magnus Hagander wrote: > For me a killer feature would be if/when we can get to a point where we can > have something pgxs-style on cmake that also works on windows. That should be quite possible. The ugliest part will be to determine where to include a cmake file

Re: [HACKERS] WIP: About CMake v2

On 02/10/2017 08:27 PM, Magnus Hagander wrote: For me a killer feature would be if/when we can get to a point where we can have something pgxs-style on cmake that also works on windows. Our homemade Windows build system works OK for postgres, and while ugly it is as you say well tested by now.

Re: [HACKERS] WIP: About CMake v2

On Fri, Feb 10, 2017 at 6:07 PM, Robert Haas wrote: > On Mon, Jan 30, 2017 at 10:26 AM, Peter Eisentraut > wrote: > > On 1/30/17 1:28 AM, Andres Freund wrote: > >> Given that fact, I just don't buy why it's a good idea to not also > >>

Re: [HACKERS] WIP: About CMake v2

On 2017-02-10 12:07:15 -0500, Robert Haas wrote: > On Mon, Jan 30, 2017 at 10:26 AM, Peter Eisentraut > wrote: > > On 1/30/17 1:28 AM, Andres Freund wrote: > >> Given that fact, I just don't buy why it's a good idea to not also > >> replace autoconf initially. >

Re: [HACKERS] WIP: About CMake v2

On Mon, Jan 30, 2017 at 10:26 AM, Peter Eisentraut wrote: > On 1/30/17 1:28 AM, Andres Freund wrote: >> Given that fact, I just don't buy why it's a good idea to not also >> replace autoconf initially. > > Well, I find it a bit scary. If you do the big switch

Re: [HACKERS] WIP: About CMake v2

Hi, On 2017-02-08 16:52:19 -0500, Tom Lane wrote: > For my own purposes, the only thing that I find seriously annoying about > the status quo is the amount of time required to run "configure". For > me, that step is usually comparable to or even more than the time to > do the build proper,

Re: [HACKERS] WIP: About CMake v2

On 2/8/17 3:52 PM, Tom Lane wrote: For my own purposes, the only thing that I find seriously annoying about the status quo is the amount of time required to run "configure". For me, that step is usually comparable to or even more than the time to do the build proper, because (a) ccache and (b)

Re: [HACKERS] WIP: About CMake v2

Peter Eisentraut writes: > On 2/8/17 6:21 AM, Yuriy Zhuravlev wrote: >> Support two build systems it's not big deal really. I have been working >> on this past year without any big troubles. >> Also we have second perl build system... > The perl/msvc build

Re: [HACKERS] WIP: About CMake v2

Hi, On 2017-01-30 10:26:18 -0500, Peter Eisentraut wrote: > On 1/30/17 1:28 AM, Andres Freund wrote: > > Given that fact, I just don't buy why it's a good idea to not also > > replace autoconf initially. > > Well, I find it a bit scary. If you do the big switch all at once, then > you will have

Re: [HACKERS] WIP: About CMake v2

On 2/8/17 6:21 AM, Yuriy Zhuravlev wrote: > Support two build systems it's not big deal really. I have been working > on this past year without any big troubles. > Also we have second perl build system... The perl/msvc build system pulls in information from the makefiles. So when you add a file

Re: [HACKERS] WIP: About CMake v2

2017-01-28 1:50 GMT+03:00 Michael Paquier : > On Fri, Jan 27, 2017 at 11:09 PM, Peter Eisentraut > wrote: > > On 1/24/17 8:37 AM, Tom Lane wrote: > >> Craig Ringer writes: > >>> Personally I think we

Re: [HACKERS] WIP: About CMake v2

> > I don't understand what this has to do with cmake. If this is a > worthwhile improvement for the Windows build, then please explain why, > with a "before" and "after" output and a patch for the existing build > system as well. During the porting process, I meet such situations when I should

Re: [HACKERS] WIP: About CMake v2

On 1/30/17 1:28 AM, Andres Freund wrote: > Given that fact, I just don't buy why it's a good idea to not also > replace autoconf initially. Well, I find it a bit scary. If you do the big switch all at once, then you will have to dedicate the following 3 months to fixing complaints from

Re: [HACKERS] WIP: About CMake v2

On 2017-01-27 22:20:41 -0500, Peter Eisentraut wrote: > On 1/27/17 6:11 PM, Andres Freund wrote: > > On 2017-01-27 09:09:36 -0500, Peter Eisentraut wrote: > >> My preferred scenario would be to replace the Windows build system by > >> this first, then refine it, then get rid of Autoconf. > >> > >>

Re: [HACKERS] WIP: About CMake v2

On Sat, Jan 28, 2017 at 12:20 PM, Peter Eisentraut wrote: > On 1/27/17 6:11 PM, Andres Freund wrote: >> On 2017-01-27 09:09:36 -0500, Peter Eisentraut wrote: >>> My preferred scenario would be to replace the Windows build system by >>> this first, then refine it,

Re: [HACKERS] WIP: About CMake v2

On 1/27/17 6:11 PM, Andres Freund wrote: > On 2017-01-27 09:09:36 -0500, Peter Eisentraut wrote: >> My preferred scenario would be to replace the Windows build system by >> this first, then refine it, then get rid of Autoconf. >> >> The ideal timeline would be to have a ready patch to commit early

Re: [HACKERS] WIP: About CMake v2

On 2017-01-27 09:09:36 -0500, Peter Eisentraut wrote: > My preferred scenario would be to replace the Windows build system by > this first, then refine it, then get rid of Autoconf. > > The ideal timeline would be to have a ready patch to commit early in a > development cycle, then get rid of the

Re: [HACKERS] WIP: About CMake v2

On Fri, Jan 27, 2017 at 11:09 PM, Peter Eisentraut wrote: > On 1/24/17 8:37 AM, Tom Lane wrote: >> Craig Ringer writes: >>> Personally I think we should aim to have this in as a non default build >>> mode in pg10 if it can be made

Re: [HACKERS] WIP: About CMake v2

Peter Eisentraut wrote: > Right now, however, the patch isn't moving at all, and I don't see it > going into PG10, so I'm fine with returning with feedback. There are a bunch of side patches that we should apply separately, such as the pgcrypto fix. I don't understand why they are part of this

Re: [HACKERS] WIP: About CMake v2

On 1/24/17 8:37 AM, Tom Lane wrote: > Craig Ringer writes: >> Personally I think we should aim to have this in as a non default build >> mode in pg10 if it can be made ready, and aim to make it default in pg11 at >> least for Windows. > > AFAIK we haven't committed

Re: [HACKERS] WIP: About CMake v2

Craig Ringer writes: > Personally I think we should aim to have this in as a non default build > mode in pg10 if it can be made ready, and aim to make it default in pg11 at > least for Windows. AFAIK we haven't committed to accepting this at all, let alone trying to

Re: [HACKERS] WIP: About CMake v2

On 24 Jan. 2017 18:00, "Andres Freund" wrote: On 2017-01-24 15:50:47 +0900, Michael Paquier wrote: > I am marking this patch as "returned with feedback". That's quite a > heavy change and it looks to be too late in the development cycle of > PG10 to consider it. Peter's

Re: [HACKERS] WIP: About CMake v2

On Tue, Jan 24, 2017 at 3:58 PM, Andres Freund wrote: > On 2017-01-24 15:50:47 +0900, Michael Paquier wrote: >> I am marking this patch as "returned with feedback". That's quite a >> heavy change and it looks to be too late in the development cycle of >> PG10 to consider it.

Re: [HACKERS] WIP: About CMake v2

On 2017-01-24 15:50:47 +0900, Michael Paquier wrote: > I am marking this patch as "returned with feedback". That's quite a > heavy change and it looks to be too late in the development cycle of > PG10 to consider it. Peter's commit bits, who is also the reviewer, > are beginning to smoke as well

Re: [HACKERS] WIP: About CMake v2

On Tue, Jan 3, 2017 at 11:11 PM, Peter Eisentraut wrote: > On 12/30/16 9:10 AM, Yuriy Zhuravlev wrote: >> cmake_v2_2_c_define.patch >> >> Small chages in c.h . At first it is “#pragma fenv_access (off)” it is >> necessary if we use /fp:strict for MSVC compiler.

Re: [HACKERS] WIP: About CMake v2

On 12/30/16 9:10 AM, Yuriy Zhuravlev wrote: > cmake_v2_2_c_define.patch > > Small chages in c.h . At first it is “#pragma fenv_access (off)” it is > necessary if we use /fp:strict for MSVC compiler. Without this pragma we > can’t calc floats for const variables in compiller time (2 * M_PI for >

Re: [HACKERS] WIP: About CMake v2

Michael Paquier wrote: src/include/port/win32.h:#define putenv(x) pgwin32_putenv(x) and my MSVC2015 drop down here because pgwin32_putenv has wrong signature. I hope it is not true now. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent

Re: [HACKERS] WIP: About CMake v2

On Wed, Nov 16, 2016 at 2:14 PM, Mark Kirkwood wrote: > I see there are some patches for the putenv issue with Visual studio 2013 in > progress on this list - it is probably best to work with the author to see > if 2015 has any new issues and keep all changes for

Re: [HACKERS] WIP: About CMake v2

I see there are some patches for the putenv issue with Visual studio 2013 in progress on this list - it is probably best to work with the author to see if 2015 has any new issues and keep all changes for that *out* of the cmake patches. regards Mark On 16/11/16 21:22, Yury Zhuravlev

Re: [HACKERS] WIP: About CMake v2

On Tue, Nov 8, 2016 at 9:12 PM, Michael Paquier wrote: > On Wed, Nov 9, 2016 at 7:54 AM, Craig Ringer > wrote: >> On 9 Nov. 2016 06:37, "Yury Zhuravlev" wrote: >>> This approach I see only in Postgres project

Re: [HACKERS] WIP: About CMake v2

Mark Kirkwood wrote: Yeah, there seems to be a lot of these. Looking through them almost all concern the addition of piece of code to wrap putenv. e.g: I made this small wrapper special for MSVC 2015 without Service Packs because postgres macross were in conflict with MS internal functions.

Re: [HACKERS] WIP: About CMake v2

Mark Kirkwood wrote: Actually, it was not that tricky to separate out the cmake only changes, and test this on unmodified sources. It appears to work fine for me - passes 'make check' (needs the v1_1 incremental patch applied of course). The Patch is attached. I wonder if the original had

Re: [HACKERS] WIP: About CMake v2

Yeah, there seems to be a lot of these. Looking through them almost all concern the addition of piece of code to wrap putenv. e.g: --- a/src/bin/psql/command.c +++ b/src/bin/psql/command.c @@ -1350,7 +1350,7 @@ exec_command(const char *cmd, char *newval;

Re: [HACKERS] WIP: About CMake v2

I had a bit a play around to see if I could get this building properly again with v10 (i.e master). I've attached a minimal *incremental* patch that needs to be applied after v1. This gets everything under the src tree building (added the new file_utils.c and reordered some link libs and

Re: [HACKERS] WIP: About CMake v2

Mark Kirkwood writes: > I would recommend making it behave as Tom suggested. *Then* add an > --autodetect or similar option that makes > behave in the 'finding and using what it could' manner as a 2nd patch. An "--autodetect" switch would be fine with me. I just

Re: [HACKERS] WIP: About CMake v2

On 11/11/16 08:15, Yury Zhuravlev wrote: Craig Ringer wrote: So personally I think it'd be fine if a cmake build defaulted to finding and using what it could, but offered a --minimal mode or whatever that gets us just core postgres + whatever we enable explicitly. But our current behaviour is

Re: [HACKERS] WIP: About CMake v2

Craig Ringer wrote: So personally I think it'd be fine if a cmake build defaulted to finding and using what it could, but offered a --minimal mode or whatever that gets us just core postgres + whatever we enable explicitly. But our current behaviour is OK too. To me it's best way. But I'm not

Re: [HACKERS] WIP: About CMake v2

Craig Ringer wrote: So personally I think it'd be fine if a cmake build defaulted to finding and using what it could, but offered a --minimal mode or whatever that gets us just core postgres + whatever we enable explicitly. But our current behaviour is OK too. To me it's best way. But I'm not

Re: [HACKERS] WIP: About CMake v2

Tom Lane wrote: So this is really not open for negotiation. As Peter said upthread, what we are looking for in a CMake reimplementation is that it behaves exactly like the Autoconf version does. To the extent that you are unable or unwilling to duplicate that behavior, you increase the odds

Re: [HACKERS] WIP: About CMake v2

Craig Ringer writes: > On 9 Nov. 2016 06:37, "Yury Zhuravlev" wrote: >> This approach I see only in Postgres project and not fully understood. >> Can you explain me more what reasons led to this approach? > It's predictable. The default

Re: [HACKERS] WIP: About CMake v2

On 9 November 2016 at 10:12, Michael Paquier wrote: > On Wed, Nov 9, 2016 at 7:54 AM, Craig Ringer > wrote: >> On 9 Nov. 2016 06:37, "Yury Zhuravlev" wrote: >>> This approach I see only in Postgres project and

Re: [HACKERS] WIP: About CMake v2

On Wed, Nov 9, 2016 at 7:54 AM, Craig Ringer wrote: > On 9 Nov. 2016 06:37, "Yury Zhuravlev" wrote: >> This approach I see only in Postgres project and not fully understood. >> Can you explain me more what reasons led to this approach? >

Re: [HACKERS] WIP: About CMake v2

On 9 Nov. 2016 06:37, "Yury Zhuravlev" wrote: > >> When I run cmake without options, it seems to do opportunistic feature >> checking. For example, it turns on OpenSSL or Python support if it can >> find it, otherwise it turns it off. We need this to be

Re: [HACKERS] WIP: About CMake v2

Hello. Peter Eisentraut wrote: I tried this out. Because of some file moves in initdb and pg_basebackup, the build fails: Yes, I need rebase patch to latest master. I do it as soon as possible. Also I have some new achievements. I suggest you use git format-patch to produce patches. This

Re: [HACKERS] WIP: About CMake v2

On 9/17/16 1:21 PM, Yury Zhuravlev wrote: > Now, I published the first version of the patch. I tried this out. Because of some file moves in initdb and pg_basebackup, the build fails: [ 74%] Linking C executable initdb Undefined symbols for architecture x86_64: "_fsync_pgdata", referenced

Re: [HACKERS] WIP: About CMake v2

Stas Kelvich wrote: Tried to generate Xcode project out of cmake, build fails on genbki.pl: can't locate Catalog.pm (which itself lives in src/backend/catalog/Catalog.pm) Thanks again! I have corrected your issue. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian

Re: [HACKERS] WIP: About CMake v2

Stas Kelvich wrote: On 17 Sep 2016, at 20:21, Yury Zhuravlev wrote: Michael Paquier wrote: ... Tried to generate Xcode project out of cmake, build fails on genbki.pl: can't locate Catalog.pm (which itself lives in src/backend/catalog/Catalog.pm) Can you

Re: [HACKERS] WIP: About CMake v2

> On 17 Sep 2016, at 20:21, Yury Zhuravlev wrote: > > Michael Paquier wrote: >> On Sat, Sep 17, 2016 at 1:40 AM, Yury Zhuravlev >> wrote: >>> Michael Paquier wrote: >>> I merged master to my branch and I spent time to porting all changes.

Re: [HACKERS] WIP: About CMake v2

On 9/16/16 9:33 AM, Michael Paquier wrote: > I am no cmake guru yet, but VPATH builds are supported out of the box, > which is cool. > > Your patch recommends to build with cmake after creating build/, now I > would expect most users to run cmake from the root folder. My understanding is that

Re: [HACKERS] WIP: About CMake v2

Andres Freund wrote: It's way too likely that we end up releasing with multiple buildsystems that way. If we fail in the CMake integration we can easily remove all CMake files before code freeze. I hope step by step CMake integration better way for current situation. But I do not insist,

Re: [HACKERS] WIP: About CMake v2

On Sat, Sep 17, 2016 at 8:11 AM, Andres Freund wrote: > Hi, > > On 2016-09-16 22:33:50 +0900, Michael Paquier wrote: >> As supporting all platforms at once with cmake is going to be >> uncommitable, we are going to need both methods able to live together >> for a while. > > I

Re: [HACKERS] WIP: About CMake v2

Hi, On 2016-09-16 22:33:50 +0900, Michael Paquier wrote: > As supporting all platforms at once with cmake is going to be > uncommitable, we are going to need both methods able to live together > for a while. I very strongly disagree with this. It's way too likely that we end up releasing with

Re: [HACKERS] WIP: About CMake v2

On Sat, Sep 17, 2016 at 1:40 AM, Yury Zhuravlev wrote: > Michael Paquier wrote: > I merged master to my branch and I spent time to porting all changes. I hope > send patch in the weekend without terrible flaws. By the way, I noticed that you did not register this

Re: [HACKERS] WIP: About CMake v2

Michael Paquier wrote: Your patch recommends to build with cmake after creating build/, now I would expect most users to run cmake from the root folder. However this causes all the Makefiles to get overwritten. As supporting all platforms at once with cmake is going to be uncommitable, we are

Re: [HACKERS] WIP: About CMake v2

On Fri, Sep 16, 2016 at 9:58 AM, Michael Paquier wrote: > Okay. That sounds good to me. I donas well a look around, and cmake really > looks like a robust alternative to ./configure. Now I am aware of the fact > that your patch recommends to build 't recall what your

Re: [HACKERS] WIP: About CMake v2

On Fri, Sep 16, 2016 at 4:38 AM, Yury Zhuravlev wrote: > Michael Paquier wrote: >> >> Could it be possible to get a refreshed patch on this thread for at >> least the sake of the archives? I'd really like to see somehting >> happening here and do some progress for this

Re: [HACKERS] WIP: About CMake v2

Michael Paquier wrote: Could it be possible to get a refreshed patch on this thread for at least the sake of the archives? I'd really like to see somehting happening here and do some progress for this CF. Sure, I will do it on Friday. Today I finished mingw+msys support. (mingw without msys

Re: [HACKERS] WIP: About CMake v2

Yury, On Mon, Aug 22, 2016 at 7:48 AM, Christian Convey wrote: >>> I glad to hear it. I suppose you can just try build postgres and send all >>> problems to github tracker. >>> https://github.com/stalkerg/postgres_cmake/issues > > FYI, I had success using your

Re: [HACKERS] WIP: About CMake v2

Hi Yury, >> I glad to hear it. I suppose you can just try build postgres and send all >> problems to github tracker. >> https://github.com/stalkerg/postgres_cmake/issues FYI, I had success using your "postgres_cmake" repo. I tested it up through "make check" and "make install". Here are the

Re: [HACKERS] WIP: About CMake v2

Hi Yury, On Fri, Aug 19, 2016 at 9:46 AM, Yury Zhuravlev wrote: > Christian Convey wrote: >> >> I'm interested in helping with your CMake effort. I don't have any >> experience contributing to PG, but I do have some free time at the >> moment. Please let me know if

Re: [HACKERS] WIP: About CMake v2

Stefan Kaltenbrunner wrote: well we have for example a NetBSD 5.1 boxe (coypu) on the buildfarm that have a software stack that is basically 2008/2009ish... So 2.8.0-2.8.3 seems like a realistic target to me still You can install fresh CMake to NetBSD without big problems from source. --

Re: [HACKERS] WIP: About CMake v2

Andres Freund wrote: The benefit cmake brings to the table, from my pov, is that it allows to get rid of somewhat a parallel buildsystem (msvc / windows, which sources most of its information from the makefiles). If we continue to have two, especially if they're entirely separate, I see little

Re: [HACKERS] WIP: About CMake v2

Stefan Kaltenbrunner wrote: On 08/18/2016 09:30 PM, Christian Convey wrote: Hi Karl, I'll need to let Yury answer your original question regarding the best way to report CMake-related bugs. Regarding the errors you're getting... I just looked at CMake's online documentation regarding your

Re: [HACKERS] WIP: About CMake v2

Christian Convey wrote: I'm interested in helping with your CMake effort. I don't have any experience contributing to PG, but I do have some free time at the moment. Please let me know if I can help. I glad to hear it. I suppose you can just try build postgres and send all problems to github

Re: [HACKERS] WIP: About CMake v2

Stefan Kaltenbrunner wrote: hmm how do you actually want reports on how it works? I just played with it on spoonbill (OpenBSD 5.3/sparc64) and got this: CMake Error at CMakeLists.txt:1250 (file): file does not recognize sub-command GENERATE CMake Error at src/port/CMakeLists.txt:156

Re: [HACKERS] WIP: About CMake v2

On Fri, Aug 19, 2016 at 4:25 AM, Tom Lane wrote: > BTW, I just noticed that cmake doesn't seem to be supplied as part of > Apple's dev tools, at least not up to current (El Capitan) releases. > That's going to be a rather large minus to be taken into account > whenever we make

Re: [HACKERS] WIP: About CMake v2

On 8/18/16 4:23 PM, Christian Convey wrote: > What standard would you suggest for those platforms which don't have > an obvious default version of CMake? In the olden days, when many platforms we supported didn't come with GNU make or other GNU tools or even a compiler, we collected a lot of

Re: [HACKERS] WIP: About CMake v2

Christian Convey writes: >> well I personally think the level to meet would be that all the systems >> on the buildfarm that can build -HEAD at the time the patch is proposed >> for a commit should be able to build using the new system with whatever >> cmake version is

Re: [HACKERS] WIP: About CMake v2

Hi Stefan, >> I ask because I'm curious if/how someone in Yury's situation could >> predict which minimum version of CMake must be supported in order for >> his patch to be accepted. (And if he accepts my offer to pitch in, >> I'll actually need that particular detail.) > > well I personally

Re: [HACKERS] WIP: About CMake v2

On 2016-08-18 15:55:20 -0400, Christian Convey wrote: > * Allow the CMake-based build system to assume a fairly modern version > of CMake. (Maybe 2.8.12, or 3.0.) > > * For systems where the minimum CMake version isn't readily available, > have an alternative build system which is just a

Re: [HACKERS] WIP: About CMake v2

Christian Convey wrote: > I see. In other projects I've worked on, the configuration of a build > farm has been driven by some list of platforms that were considered > important to support. Build farm members are systems that somebody has seen as interesting enough that they deserve enough

Re: [HACKERS] WIP: About CMake v2

> > I don't think we're interested in maintaining more build systems than we > already are. If cmake can replace the current MSVC tooling and > autoconf, all in one, my impression is that we're in. If we're > replacing two tools we've hammered pretty well over the years with two > tools that we

Re: [HACKERS] WIP: About CMake v2

Christian Convey wrote: > * Allow the CMake-based build system to assume a fairly modern version > of CMake. (Maybe 2.8.12, or 3.0.) > > * For systems where the minimum CMake version isn't readily available, > have an alternative build system which is just a simplistic Bash > script that

Re: [HACKERS] WIP: About CMake v2

Hi Tom, >> I ask because I'm curious if/how someone in Yury's situation could >> predict which minimum version of CMake must be supported in order for >> his patch to be accepted. (And if he accepts my offer to pitch in, >> I'll actually need that particular detail.) > > well I personally think

Re: [HACKERS] WIP: About CMake v2

On 08/18/2016 09:52 PM, Alvaro Herrera wrote: > Stefan Kaltenbrunner wrote: >> On 08/18/2016 09:30 PM, Christian Convey wrote: > >>> Yury: Would it make sense to add a call to "cmake_minimum_required" in >>> one or more of your CMakeLists.txt files? >> >> it would make sense nevertheless but I

Re: [HACKERS] WIP: About CMake v2

Hi Stefan, >> Yury: Would it make sense to add a call to "cmake_minimum_required" in >> one or more of your CMakeLists.txt files? > > it would make sense nevertheless but I dont think that 2.8.11 is old > enough - looking at the release information and the feature compatibily > matrix it would

Re: [HACKERS] WIP: About CMake v2

On 08/18/2016 09:42 PM, Christian Convey wrote: > Hi Tom, > > Thanks for that information. > > Is there some document I can read that explains which platform > versions (e.g., OpenBSD 5.3) are considered strongly supported? well not sure we have very clear document on that - I would say that

Re: [HACKERS] WIP: About CMake v2

Stefan Kaltenbrunner wrote: > On 08/18/2016 09:30 PM, Christian Convey wrote: > > Yury: Would it make sense to add a call to "cmake_minimum_required" in > > one or more of your CMakeLists.txt files? > > it would make sense nevertheless but I dont think that 2.8.11 is old > enough - looking at

Re: [HACKERS] WIP: About CMake v2

Hi Tom, Thanks for that information. Is there some document I can read that explains which platform versions (e.g., OpenBSD 5.3) are considered strongly supported? I ask because I'm curious if/how someone in Yury's situation could predict which minimum version of CMake must be supported in

Re: [HACKERS] WIP: About CMake v2

On 08/18/2016 09:30 PM, Christian Convey wrote: > Hi Karl, > > I'll need to let Yury answer your original question regarding the best > way to report CMake-related bugs. > > Regarding the errors you're getting... I just looked at CMake's > online documentation regarding your

Re: [HACKERS] WIP: About CMake v2

Hi Karl, I'll need to let Yury answer your original question regarding the best way to report CMake-related bugs. Regarding the errors you're getting... I just looked at CMake's online documentation regarding your "target_compile_definitions" error. >From what I can tell, the

Re: [HACKERS] WIP: About CMake v2

Stefan Kaltenbrunner writes: > On 08/18/2016 08:57 PM, Christian Convey wrote: >> Which version of CMake gave you those errors? (Sorry if you provided >> that detail and I'm just missing it.) > % cmake --version > cmake version 2.8.10.2 > a quick look in the docs does

Re: [HACKERS] WIP: About CMake v2

On 08/18/2016 08:57 PM, Christian Convey wrote: > Hi Stefan, > > I think I've seen similar errors when a project's CMake files assumed > a newer version of CMake than the one being run. > > Which version of CMake gave you those errors? (Sorry if you provided > that detail and I'm just missing

Re: [HACKERS] WIP: About CMake v2

Hi Stefan, I think I've seen similar errors when a project's CMake files assumed a newer version of CMake than the one being run. Which version of CMake gave you those errors? (Sorry if you provided that detail and I'm just missing it.) Kind regards, Christian On Thu, Aug 18, 2016 at 2:45 PM,

Re: [HACKERS] WIP: About CMake v2

On 06/29/2016 06:23 PM, Yury Zhuravlev wrote: > Hello Hackers. > > I decided to talk about the current state of the project: > 1. Merge with 9.6 master. 2. plpython2, plpython3, plperl, pltcl, plsql > all work correctly (all tests pass). > 3. Works done for all contrib modules. 4. You can use

Re: [HACKERS] WIP: About CMake v2

Hi Yury, I'm interested in helping with your CMake effort. I don't have any experience contributing to PG, but I do have some free time at the moment. Please let me know if I can help. I have an intermediate level of experience with CMake, Python, and Bash scripting. My native environment is

Re: [HACKERS] WIP: About CMake v2

Hi! I think, we need simple configure script generator for backward compatibility and easy using this build system. Try playing with cmake build system under Win2008+MinGW. I plan to write perl script for automatic build this with depends. On 29.06.2016 19:23, Yury Zhuravlev wrote: Hello

Re: [HACKERS] WIP: About CMake v2

Michael Paquier wrote: Personally I am allergic to any kind of UIs for development, and I am sure not to be the only one on this list. Andrew Dunstan: We need this to be scriptable, not using a GUI. GUI is strong optional feature. Helpful for some tasks. -- Yury Zhuravlev Postgres

  1   2   >