Re: win32 version info - Mailing list pgsql-patches

From Magnus Hagander
Subject Re: win32 version info
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE4569B1@algol.sollentuna.se
Whole thread Raw
In response to win32 version info  ("Magnus Hagander" <mha@sollentuna.net>)
Responses Re: win32 version info
Re: win32 version info
List pgsql-patches
>> Makefile.global or similar could define the build rule once, like
>
>> %.o: %.rc
>>     windres -DFILEDESC=$(FILEDESC) $< -o $@
>> --include-dir=$(top_builddir)/src/include
>
>Actually, I was wondering if we could not include this in a build rule
>for executables, so that it's not necessary for the individual
>Makefiles
>to be explicitly aware of it at all ...

Ok. I got part of the way, by putting the following in Makefile.global:
ifeq ($(PORTNAME), win32)
win32ver.o: $(top_builddir)/src/port/win32ver.rc
    sed "s/FILEDESC/\"$(FILEDESC)\"/"
$(top_builddir)/src/port/win32ver.rc | windres -o win32ver.o
--include-dir=$(top_builddir)/src/include
endif

(couldn't get the -D stuff to escape things right... It would put a
backslash in front of every space - that's the closest I got. So I moved
to sed. Thanks anyway, Andrew, sent me off in the right direction.)


All that is then needed is to teach each binary to link in "win32ver.o".
For initdb, I've done this like:
ifeq ($(PORTNAME), win32)
FILEDESC=initdb - initialize a new database cluster
OBJS+=win32ver.o
endif


I assume what you would like is to have just the FILEDESC row in there?
Two questions about that:
1) How would I go about to have the Makefile actually build those files
and link them in without explicitly teaching it about it? I guess I
could link them in by adding it to LDFLAGS or something like that (feels
kind of hackish, though), but I need to have it build it as well, right?
And that line just contains $(OBJS) and libpq.a... None of wich is
inherited from Makefile.global, from what I can tell.
One way would be to just add something like $(PORTOBJ) and have
Makefile.global add whatever special .o files are required for the
current port. That way we wouldn't teach it specifically about the win32
version stuff, but we'd still have to teach it to look somewhere...
Or am I missing some other piece of the Makefile puzzle?

2) This whole concept is not going to work too well with for example
pg_dump which builds three different binaries from the same Makefile.
But I guess they could all be given some kind of shared description (as
I already did for all the stuff in bin/scripts) - that would be good
enough for me.


Mainly, I'd need help with (1) before I can proceed at all down this
path. I just have no idea how to do that.

//Magnus

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: win32 version info
Next
From: Peter Eisentraut
Date:
Subject: Re: win32 version info