pgsql: Append major version number and for libraries soname major

petere@postgresql.org (Peter Eisentraut) writes:

Log Message:
-----------
Append major version number and for libraries soname major version number
to the gettext domain name, to simplify parallel installations.

The results from buildfarm member red_bat suggest that this commit broke
the MSVC build. (I think that is the only MSVC buildfarm member that's
up at the moment.)

Build FAILED.
.\src\port\exec.c(633): error C2146: syntax error : missing ')' before identifier 'PG_MAJORVERSION'
.\src\backend\main\main.c(90): error C2146: syntax error : missing ')' before identifier 'PG_MAJORVERSION'
.\src\port\exec.c(633): error C2146: syntax error : missing ')' before identifier 'PG_MAJORVERSION'
0 Warning(s)
3 Error(s)

regards, tom lane

On Fri, Dec 12, 2008 at 12:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

petere@postgresql.org (Peter Eisentraut) writes:

Log Message:
-----------
Append major version number and for libraries soname major version number
to the gettext domain name, to simplify parallel installations.

The results from buildfarm member red_bat suggest that this commit broke
the MSVC build. (I think that is the only MSVC buildfarm member that's
up at the moment.)

Build FAILED.
.\src\port\exec.c(633): error C2146: syntax error : missing ')' before identifier 'PG_MAJORVERSION'
.\src\backend\main\main.c(90): error C2146: syntax error : missing ')' before identifier 'PG_MAJORVERSION'
.\src\port\exec.c(633): error C2146: syntax error : missing ')' before identifier 'PG_MAJORVERSION'
0 Warning(s)
3 Error(s)

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 motherboard for their box).

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Dave Page wrote:

On Fri, Dec 12, 2008 at 12:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

petere@postgresql.org (Peter Eisentraut) writes:

Log Message:
-----------
Append major version number and for libraries soname major version number
to the gettext domain name, to simplify parallel installations.

The results from buildfarm member red_bat suggest that this commit broke
the MSVC build. (I think that is the only MSVC buildfarm member that's
up at the moment.)

Build FAILED.
.\src\port\exec.c(633): error C2146: syntax error : missing ')' before identifier 'PG_MAJORVERSION'
.\src\backend\main\main.c(90): error C2146: syntax error : missing ')' before identifier 'PG_MAJORVERSION'
.\src\port\exec.c(633): error C2146: syntax error : missing ')' before identifier 'PG_MAJORVERSION'
0 Warning(s)
3 Error(s)

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 motherboard for their box).

I think the maintenance of the MSVC build system is the job of the,
well, maintainer of the MSVC build system, whoever that may be. In
other words, I have no ETA for you from me. I'd be glad, however, to
provide information to the maintainers.

The fix here is to define PG_MAJORVERSION near whereever you define
PG_VERSION, just make it look like "8.4" instead of "8.4devel".

Magnus?

On Tue, Dec 16, 2008 at 10:47 AM, Peter Eisentraut <peter_e@gmx.net> wrote:

I think the maintenance of the MSVC build system is the job of the, well,
maintainer of the MSVC build system, whoever that may be. In other words, I
have no ETA for you from me. I'd be glad, however, to provide information
to the maintainers.

The fix here is to define PG_MAJORVERSION near whereever you define
PG_VERSION, just make it look like "8.4" instead of "8.4devel".

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Peter Eisentraut <peter_e@gmx.net> 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 motherboard for their box).

I think the maintenance of the MSVC build system is the job of the,
well, maintainer of the MSVC build system, whoever that may be. In
other words, I have no ETA for you from me. I'd be glad, however, to
provide information to the maintainers.

I do not think this is an appropriate attitude for a committer to take.
You are responsible for what you commit. If you don't have the
knowledge to fix something, or the resources to test it, okay ... but
you then need to be proactive about getting someone else to fix/test it.
Or else revert the broken patch.

regards, tom lane

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> 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 motherboard for their box).

I think the maintenance of the MSVC build system is the job of the,
well, maintainer of the MSVC build system, whoever that may be. In
other words, I have no ETA for you from me. I'd be glad, however, to
provide information to the maintainers.

I do not think this is an appropriate attitude for a committer to take.
You are responsible for what you commit. If you don't have the
knowledge to fix something, or the resources to test it, okay ... but
you then need to be proactive about getting someone else to fix/test it.
Or else revert the broken patch.

I agree. I have committed an attempted fix which I discussed briefly
with Magnus.

cheers

andrew

On Tuesday 16 December 2008 16:53:26 Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> 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 motherboard for their box).

I think the maintenance of the MSVC build system is the job of the,
well, maintainer of the MSVC build system, whoever that may be. In
other words, I have no ETA for you from me. I'd be glad, however, to
provide information to the maintainers.

I do not think this is an appropriate attitude for a committer to take.
You are responsible for what you commit. If you don't have the
knowledge to fix something, or the resources to test it, okay ... but
you then need to be proactive about getting someone else to fix/test it.
Or else revert the broken patch.

I would like to have this clarified, as I keep running afoul of it.

We originally did the Windows port using the MinGW build system because we did
not want to maintain another build system. When people starting on the MSVC
build system, I was given assurances that they would maintain it and we would
not have to worry about it. I specifically recall discussions about that in
Toronto in 2006.

Now who are those maintainers and what are they doing about it?

I am not hostile against the MSVC system, even though I have no interest in it
(and I am unfamiliar with the payoff). I have done a lot of portability work
for crazy platforms that I have no stake in. But those platforms and build
systems used standard tools, had publically available documentation, and in
the extreme cases had a box that one could log into to verify the work. None
of this is available here. I don't think the progress of this project can
depend on proprietary tools and systems in a few hands.

Help?!?

Peter Eisentraut <peter_e@gmx.net> 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
uninterested in doing so. But it would be appropriate to post a note
to -hackers when you make a build system change that is going to need
to be reflected in those scripts. The people who do care about MSVC
should not have to find that out by watching the buildfarm and then
trying to reverse-engineer the cause of a failure.

regards, tom lane

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> 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
uninterested in doing so. But it would be appropriate to post a note
to -hackers when you make a build system change that is going to need
to be reflected in those scripts. The people who do care about MSVC
should not have to find that out by watching the buildfarm and then
trying to reverse-engineer the cause of a failure.

As one of said people, I think that's perfectly reasonable. It'd make it
a lot easier to get a heads-up, or just the version of the patch right
before a commit to add it to. Some people do that, some don't - it would
be muchos helpful if all did.

I don't expect unix hackers to always patch the msvc system as needed -
given that you don't have a way to test it, and no experience how those
tools work. (I know Tom has made a number of smaller fixes in them, but
it's mostly been around the areas of smaller changes, not actually
adding new stuff, for exmaple)

If I had warning this time, for example, I could've said that I for one
can't fix that for a while, because my msvc build system is all geared
up around the git server (because it's so much easier to get the stuff
in and out of the VM when cross-deveoping than with CVS and the crippled
commandline toolchain on windows). And since that one is currently not
working properly, I need to find a different way to get the code in
there unless someone can fix it :-(

Hopefully someone else can pick it up this time around? If not, I'll do
it as soon as I get things back up and working in my env.

//Magnus

Exactly what type of changes affec the MSVC build system?

---------------------------------------------------------------------------

Magnus Hagander wrote:

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> 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
uninterested in doing so. But it would be appropriate to post a note
to -hackers when you make a build system change that is going to need
to be reflected in those scripts. The people who do care about MSVC
should not have to find that out by watching the buildfarm and then
trying to reverse-engineer the cause of a failure.

As one of said people, I think that's perfectly reasonable. It'd make it
a lot easier to get a heads-up, or just the version of the patch right
before a commit to add it to. Some people do that, some don't - it would
be muchos helpful if all did.

I don't expect unix hackers to always patch the msvc system as needed -
given that you don't have a way to test it, and no experience how those
tools work. (I know Tom has made a number of smaller fixes in them, but
it's mostly been around the areas of smaller changes, not actually
adding new stuff, for exmaple)

If I had warning this time, for example, I could've said that I for one
can't fix that for a while, because my msvc build system is all geared
up around the git server (because it's so much easier to get the stuff
in and out of the VM when cross-deveoping than with CVS and the crippled
commandline toolchain on windows). And since that one is currently not
working properly, I need to find a different way to get the code in
there unless someone can fix it :-(

Hopefully someone else can pick it up this time around? If not, I'll do
it as soon as I get things back up and working in my env.

//Magnus

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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 a new subdir that
adds more files to an existing target, should require no changes.

//Magnus

Bruce Momjian wrote:

Magnus Hagander <magnus@hagander.net> 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
scripts that run (like gen_fmgr.sh).

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 were new build
targets, or ??

regards, tom lane

Tom Lane wrote:

Magnus Hagander <magnus@hagander.net> 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
scripts that run (like gen_fmgr.sh).

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 were new build
targets, or ??

Yes, they are new build targets, that's why it didn't catch them.

//Magnus

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 were new build
targets, or ??

Yes, they are new build targets, that's why it didn't catch them.

Also, because one of the Makefiles involved (src/foreign/Makefile)
doesn't follow one of our standard patterns.

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.

cheers

andrew

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 http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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, indeed.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> 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

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> 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 linked into the backend
itself? They are supposed to be different build targets...

It's more like the conversion_procs stuff, which also doesn't use
SUBDIRS - it uses DIRS, but he idea is the same as FDW.

//Magnus

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 somebody to do the work.

It did play around with CMake a while back. It works OK. I had libpq and
psql building, for example. The problem I see is that converting the build
system will probably take many man-hours, and in the meantime, it would
essentially create yet another build system to maintain. Plus, we are not
sure, of course, whether we will end up adopting CMake.

My preferred approach now is that the existing makefiles need to be refactored
more aggressively first, using make functions. We could incidentally design
those functions similar to the CMake declarations, so a conversion, if we
decided to do one, would be simple. But doing that properly would require a
newer GNU make version, so it needs some consideration first. (I'm not
talking about last week's release, but more like 4 years old versus the 10
years old that we currently require.)

We can revisit this for the next release cycle.