I took the ai file, reduced it to the right sizes in photoshop and
used an icon editor to make it at various resolutions.
Gavin
On Sun, 1 Aug 2004 00:25:55 +0200, Magnus Hagander [EMAIL PROTECTED] wrote:
It's platform specific, therefor it should go in port/.
The criterion for port/ is not
On Sat, Jul 31, 2004 at 05:40:34PM -0700, Gavin M. Roy wrote:
I took the ai file, reduced it to the right sizes in photoshop and
used an icon editor to make it at various resolutions.
Can this be done programatically using, say, ImageMagick?
--
Alvaro Herrera (alvherre[a]dcc.uchile.cl)
The
Magnus Hagander wrote:
* Just two files to add - both go in src/port. (Moved the icon there
per discussion on IM with Bruce)
Can you post the rationale? It seem an odd place for it.
But it still holds that we
a) should not put binary files in our CVS
b) cannot put binary files without
* Just two files to add - both go in src/port. (Moved the icon there
per discussion on IM with Bruce)
Can you post the rationale? It seem an odd place for it.
We might want to link it into other binaries in the future, therefor it
should not go under psql/.
It's platform specific, therefor
Magnus Hagander wrote:
It's platform specific, therefor it should go in port/.
The criterion for port/ is not whether something is platform-specific.
It's whether it's a module that helps porting source code. Which this
is not. Maybe we should add a new directory that contains icons and
It's platform specific, therefor it should go in port/.
The criterion for port/ is not whether something is
platform-specific.
It's whether it's a module that helps porting source code. Which this
is not. Maybe we should add a new directory that contains icons and
other random auxiliary
Perhaps a compromise would be to set versioninfo on
libpq.dll (which
we alerady do), and on all the EXEs, and ignore the rest of
the DLLs.
It's not ideal, but it's a great deal better than nothing at all.
If that is an option, why not just put versions into the
build-time linkable
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Magnus Hagander
Sent: 30 July 2004 09:58
To: Peter Eisentraut
Cc: Andrew Dunstan; [EMAIL PROTECTED]
Subject: Re: [PATCHES] win32 version info
Perhaps a compromise would be to set versioninfo
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?
Magnus Hagander said:
One more thing I realised - we need two different types of versioninfo
structures, because one fields tells wether it's a DLL or an app. How
would you prefer this done - either using $(WIN32VERDLL)/$(WIN32VERAPP)
(or $(PORTOBJSHLIB)/$(PORTOBJAPP) if we go down that
One more thing I realised - we need two different types of
versioninfo
structures, because one fields tells wether it's a DLL or
an app. How
would you prefer this done - either using
$(WIN32VERDLL)/$(WIN32VERAPP) (or
$(PORTOBJSHLIB)/$(PORTOBJAPP) if we
go down that route), or
Oh, and for the record, we version libpq.dll on windows in the 7.x.y
manner, and have been doing so ever since we first added
win32 support.
We can't really back that one down, so we'd need an
exception for that
one.
This one *does* matter, because it's the main library other
Am Donnerstag, 29. Juli 2004 14:46 schrieb Magnus Hagander:
2) We'll *have* to start actually bumping at least minor versions
whenever we change the code in a sharaed lib. Which we don't do now,
except for libpq. For example, plperl still says 0.0, and plpgsql says
1.0. Also, all the
Magnus Hagander wrote:
Perhaps a compromise would be to set versioninfo on libpq.dll (which
we alerady do), and on all the EXEs, and ignore the rest of the DLLs.
It's not ideal, but it's a great deal better than nothing at all.
If that is an option, why not just put versions into the
Claudio Natoli wrote:
Seems inconsistent to me.
There is no inconsistency, as the two requirements are aimed at very
different issues. It was just the case that one (win32 versioning) was
inadvertently a potential (and rejected) solution to the other (auto version
check).
The question
Magnus Hagander [EMAIL PROTECTED] writes:
This patch along with the attached files (.tar.gz unpacks in src/) adds
VERSIONINFO to all binaries under win32.
Ya know, this is the sort of invasive junk that I was afraid people
would try to force on us for the Windows port :-(.
Can't you localize
This patch along with the attached files (.tar.gz unpacks in src/)
adds VERSIONINFO to all binaries under win32. This is generally
considered a good thing
Out of curiosity: Why?
Well, because it allows the user as well as other programs to identify
what version of a file is installed. For
This patch along with the attached files (.tar.gz unpacks in
src/) adds
VERSIONINFO to all binaries under win32.
Ya know, this is the sort of invasive junk that I was afraid people
would try to force on us for the Windows port :-(.
I fail to see how this is so invasive. And I definitly don't
Magnus Hagander wrote:
Can't you localize this into a single build rule somewhere? And surely
we do not need to maintain a boilerplate .rc file for every executable.
There is a field in the RC file that is file description. It's pretty
much different for every file. (There is also a
Magnus Hagander wrote:
Well, because it allows the user as well as other programs to
identify what version of a file is installed.
psql --version
For error-checking
purposes (which DLL version is really there? And debugger will also
tell you which version of the DLL is actually loaded in
Well, because it allows the user as well as other programs to
identify what version of a file is installed.
psql --version
That works for an executable. And that works for the user. Doesn't work
as well for a piece of software that does this. How is it supposed to
know which .EXEs it can send
Andrew Dunstan [EMAIL PROTECTED] writes:
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,
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
Magnus Hagander [EMAIL PROTECTED] writes:
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
Magnus Hagander wrote:
1) How would I go about to have the Makefile actually build those
files and link them in without explicitly teaching it about it?
There is no (useful) implicit rule to build executables. Either you
make one up (difficult), or you just do the explicit thing.
--
Peter
Tom Lane wrote:
I was originally thinking of somehow migrating the executable build
rules into a single pattern rule, but given the lack of any suffix on
executable names it's not clear how to use a pattern rule for the
purpose.
You can write a rule for that using
%: %.o
but...
And the
Magnus Hagander wrote:
This patch along with the attached files (.tar.gz unpacks in src/)
adds VERSIONINFO to all binaries under win32. This is generally
considered a good thing
Out of curiosity: Why?
Well, because it allows the user as well as other programs to identify
what version
27 matches
Mail list logo
