Jonah H. Harris escribió:
> On Mon, Dec 29, 2008 at 11:47 AM, Tom Lane wrote:
> > But of course those are just as straightforward in autoconf. It's
> > the not-straightforward stuff that's going to be a PITA to translate.
>
> As much as I dislike autotools, I really despise CMake; it's a nasty
>
Jonah H. Harris wrote:
> On Mon, Dec 29, 2008 at 11:47 AM, Tom Lane wrote:
> > But of course those are just as straightforward in autoconf. It's
> > the not-straightforward stuff that's going to be a PITA to translate.
>
> As much as I dislike autotools, I really despise CMake; it's a nasty
> pi
On Mon, Dec 29, 2008 at 11:47 AM, Tom Lane wrote:
> But of course those are just as straightforward in autoconf. It's
> the not-straightforward stuff that's going to be a PITA to translate.
As much as I dislike autotools, I really despise CMake; it's a nasty
piece of work and I hope we don't swi
"Dave Page" writes:
> On Mon, Dec 29, 2008 at 12:49 PM, Magnus Hagander wrote:
>> ... The point being that I think creating the
>> replacement parts for autoconf are a lot harder than creating them for
>> the make parts of the system.
> I did - in the wxWidgets case, the existing module had some
On Mon, Dec 29, 2008 at 12:49 PM, Magnus Hagander wrote:
> I did a similar thing for pgAdmin, and I found it pretty easy to do.
> However, I think Dave spent some time on doing the "plugins" for
> detecting wxWidgets and such. The point being that I think creating the
> replacement parts for autoc
Peter Eisentraut wrote:
> On Sunday 21 December 2008 00:59:27 Alvaro Herrera wrote:
>> Andrew Dunstan wrote:
>>> We (i.e. probably Magnus and I in the first instance) should think about
>>> creating a bit of a cookbook if we're going to persist with this build
>>> system.
>> Well, we were going to
On Sunday 21 December 2008 00:59:27 Alvaro Herrera wrote:
> Andrew Dunstan wrote:
> > We (i.e. probably Magnus and I in the first instance) should think about
> > creating a bit of a cookbook if we're going to persist with this build
> > system.
>
> Well, we were going to try CMake, but we need som
Tom Lane wrote:
> Andrew Dunstan writes:
>> Also, because one of the Makefiles involved (src/foreign/Makefile)
>> doesn't follow one of our standard patterns.
>
> Is there a really good reason why it doesn't?
> (eg, why "FDW" and not "SUBDIRS"?)
If you put them in SUBDIRS, don't get they get li
Alvaro Herrera wrote:
Andrew Dunstan wrote:
We (i.e. probably Magnus and I in the first instance) should think about
creating a bit of a cookbook if we're going to persist with this build
system.
Well, we were going to try CMake, but we need somebody to do the work.
Yes, in
Andrew Dunstan writes:
> Also, because one of the Makefiles involved (src/foreign/Makefile)
> doesn't follow one of our standard patterns.
Is there a really good reason why it doesn't?
(eg, why "FDW" and not "SUBDIRS"?)
regards, tom lane
--
Sent via pgsql-hackers maili
Andrew Dunstan wrote:
> We (i.e. probably Magnus and I in the first instance) should think about
> creating a bit of a cookbook if we're going to persist with this build
> system.
Well, we were going to try CMake, but we need somebody to do the work.
--
Alvaro Herrera
Magnus Hagander wrote:
Just adding new files to exisitng makefiles, or adding a new subdir that
adds more files to an existing target, should require no changes.
It might help clarify things if you say why it *didn't* pick up these
new foreign-server libraries. Is it because they wer
Tom Lane wrote:
> Magnus Hagander writes:
>>> Exactly what type of changes affec the MSVC build system?
>
>> Anything the system doesn't pick up automatically. That means most new
>> build targets (but it will pick up a contrib automatically, and a
>> conversion proc, for example). Also if modifi
Magnus Hagander writes:
>> Exactly what type of changes affec the MSVC build system?
> Anything the system doesn't pick up automatically. That means most new
> build targets (but it will pick up a contrib automatically, and a
> conversion proc, for example). Also if modifications are made to the
Anything the system doesn't pick up automatically. That means most new
build targets (but it will pick up a contrib automatically, and a
conversion proc, for example). Also if modifications are made to the
scripts that run (like gen_fmgr.sh).
Just adding new files to exisitng makefiles, or adding
Exactly what type of changes affec the MSVC build system?
---
Magnus Hagander wrote:
> Tom Lane wrote:
> > Peter Eisentraut writes:
> >> On Tuesday 16 December 2008 16:53:26 Tom Lane wrote:
> >>> I do not think this is an a
Tom Lane wrote:
> Peter Eisentraut writes:
>> On Tuesday 16 December 2008 16:53:26 Tom Lane wrote:
>>> I do not think this is an appropriate attitude for a committer to take.
>
>> I would like to have this clarified, as I keep running afoul of it.
>
> My two cents: I don't expect you to fix the
Peter Eisentraut writes:
> On Tuesday 16 December 2008 16:53:26 Tom Lane wrote:
>> I do not think this is an appropriate attitude for a committer to take.
> I would like to have this clarified, as I keep running afoul of it.
My two cents: I don't expect you to fix the MSVC scripts if you are
uni
On Tuesday 16 December 2008 16:53:26 Tom Lane wrote:
> Peter Eisentraut writes:
> > Dave Page wrote:
> >> Any eta on a fix for this? My internal builds are failing as well as
> >> red_bat. (and yes, the other 2 MSVC buildfarm members are currently
> >> waiting for Dell to get hold of a new motherb
19 matches
Mail list logo
