Re: [PATCHES] win32 version info - try 2
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 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 files such as .desktop files for Linux desktops. Sure, that works for me. It's a simple path change in Makefile.global.in. So whatever works for you guys. Is it the concept of non-sourcecode, or is it the fact that it's actually binary that is the issue? E.g. will it help if we for example uuencoded it and then just uudecode:ed it in a build rule? The problem isn't so much binary files vs. CVS, although that is an annoyance to take into account. The issue is that we need to have the source code for all files that we distribute, where source code is the preferred form for modification. This is a legal issue, a philosophical issue, and a practical issue. If you say the icon is created by hand, then that's OK, although up to now I've created all icons programmatically from, say, a PNG or SVG source. Well, what I did was, as I wrote in my original mail, download it from http://pgsql.gavinroy.com/art/. AFAIK the original source of it is a ..ai file, though. I'll have to ask Gavin about how the file was actually created, it if twas done manually or through an automatable process. Gavin - hopefully you can say something on how it's done? Thanks. //Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] win32 version info - try 2
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 West won the world not by the superiority of its ideas or values or religion but rather by its superiority in applying organized violence. Westerners often forget this fact, non-Westerners never do. (Samuel P. Huntington) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] win32 version info - try 2
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 source in our CVS We can import the original format (or some variant) and create the icon at build time. This would also be better for other distributors. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] win32 version info - try 2
* 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 it should go in port/. But it still holds that we a) should not put binary files in our CVS Why exactly is this? I asked before, and the only response I ever got (off-list) was that we actually could... b) cannot put binary files without source in our CVS See (a). We can import the original format (or some variant) and create the icon at build time. This would also be better for other distributors. The source is in .ai format, and there is manual work to convert it into a good quality .ico, from what I read on the authors page. AFAIK, .ai is also binary, and it's hard to put a person in a Makefile. Is it the concept of non-sourcecode, or is it the fact that it's actually binary that is the issue? E.g. will it help if we for example uuencoded it and then just uudecode:ed it in a build rule? //Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] win32 version info - try 2
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 other random auxiliary files such as .desktop files for Linux desktops. Is it the concept of non-sourcecode, or is it the fact that it's actually binary that is the issue? E.g. will it help if we for example uuencoded it and then just uudecode:ed it in a build rule? The problem isn't so much binary files vs. CVS, although that is an annoyance to take into account. The issue is that we need to have the source code for all files that we distribute, where source code is the preferred form for modification. This is a legal issue, a philosophical issue, and a practical issue. If you say the icon is created by hand, then that's OK, although up to now I've created all icons programmatically from, say, a PNG or SVG source. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] win32 version info - try 2
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 files such as .desktop files for Linux desktops. Sure, that works for me. It's a simple path change in Makefile.global.in. So whatever works for you guys. Is it the concept of non-sourcecode, or is it the fact that it's actually binary that is the issue? E.g. will it help if we for example uuencoded it and then just uudecode:ed it in a build rule? The problem isn't so much binary files vs. CVS, although that is an annoyance to take into account. The issue is that we need to have the source code for all files that we distribute, where source code is the preferred form for modification. This is a legal issue, a philosophical issue, and a practical issue. If you say the icon is created by hand, then that's OK, although up to now I've created all icons programmatically from, say, a PNG or SVG source. Well, what I did was, as I wrote in my original mail, download it from http://pgsql.gavinroy.com/art/. AFAIK the original source of it is a .ai file, though. I'll have to ask Gavin about how the file was actually created, it if twas done manually or through an automatable process. Gavin - hopefully you can say something on how it's done? Thanks. //Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] win32 version info
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 DLLs, which really need a version, and leave it out for the rest. Clearly, we cannot put a version into every file anyway (headers files, etc.), so everything must have a version does not hold anyway, unless there is some weird rule again that certain things must have one. As for DLLs, yes, that sounds reasonable. We also need to put it on the EXEs. That would mean which DLLS? libpq.dll and pgevent.dll definitly. Any of the ecpg dlls? If we limit ourselves to these libs, are you fine with keeping the 7.5.x version numbering there? (As said before, for libpq we don't have much choice, and pgevent.dll has no other versioning scheme anyway, since it's brand new and win32 only) As said, not ideal, but good enough I think. I think the rule generally is any EXE and DLL. But as long as it's a private DLL that nobody else ever uses, I think it's reasonable to skip the rule there. //Magnus ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] win32 version info
-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 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 DLLs, which really need a version, and leave it out for the rest. Clearly, we cannot put a version into every file anyway (headers files, etc.), so everything must have a version does not hold anyway, unless there is some weird rule again that certain things must have one. As for DLLs, yes, that sounds reasonable. We also need to put it on the EXEs. That would mean which DLLS? libpq.dll and pgevent.dll definitly. Any of the ecpg dlls? If we limit ourselves to these libs, are you fine with keeping the 7.5.x version numbering there? (As said before, for libpq we don't have much choice, and pgevent.dll has no other versioning scheme anyway, since it's brand new and win32 only) As said, not ideal, but good enough I think. I think the rule generally is any EXE and DLL. But as long as it's a private DLL that nobody else ever uses, I think it's reasonable to skip the rule there. //Magnus I've just had a look at a Linux install of 7.4.2 and the version numbering that is present in the /lib and /bin directories. To make things consistent, I would suggest the following approach for applying version information on a per directory basis: /bin- release numbering, e.g. 7.5.x for all EXE/DLL /lib- library numbering, e.g. libpq.dll should be version 3.1, libecpg.dll should be version 4.1 for all DLL /lib/postgresql - release numbering, e.g. 7.5.x for all DLL since these DLLs are used internally by the PostgreSQL server There doesn't seem much point in versioning anything else. To me, it makes more sense to version the libraries such as libpq.dll like their UNIX-based counterparts so the version numberings are consistent between the two. I can see a scenario using release numbering where an application linked to libpq.dll could fail if it checked to ensure the version matched the one it expected, even though an upgrade would not always be necessary if the FE/BE protocol remained unchanged; here the library numbering gives the better indication of the capabilities of the DLL, since any changes in protocol behaviour would be reflected by a change in the major/minor of the version number. Incidentally I've just noticed from my Win32 build a couple of months back that /lib and /lib/postgresql have been combined into /lib. Would this make it more difficult to have different versioning schemes for internal PostgreSQL libraries and the external client libraries as suggested above? Kind regards, Mark. --- Mark Cave-Ayland Webbased Ltd. Tamar Science Park Derriford Plymouth PL6 8BX England Tel: +44 (0)1752 764445 Fax: +44 (0)1752 764446 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] win32 version info
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? That would be ideal, but this is probably close enough if no one has a great idea about how to get rid of the manual addition to $(OBJS). Ok. Since nobody has added anything, I assume there is nobody around with an idea on how to do that. :-( 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... Yeah, that's not a bad idea. If anyone can think of plausible reasons why we might end up with other things needing to be built for every executable, it would be quite reasonable to go this route. Again, since nobody said anything, I assume nobody had an idea there. The question then - would you prefer me to add $(WIN32VER) to specify what it is, or should I go with $(PORTOBJ) anyway, in case we find something in the future? 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. And the existing rules are diverse enough that it might be a real pain to construct such a pattern rule anyway. Yeah, that's what I figured. 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 by setting another field along FILEDESC called FILETYPE or similar? //Magnus ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] win32 version info
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 route), or by setting another field along FILEDESC called FILETYPE or similar? I think I would go with PORTOBJ + FILEDESC + FILETYPE for now. ISTM that gets it clean enough, and it can be revisited later if necessary. One thing that I think Peter referred to - libraries that we version (e.g. libpq) in standard Unix major.minor style should probably carry that version rather than the PostgreSQL version number. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] win32 version info
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 by setting another field along FILEDESC called FILETYPE or similar? I think I would go with PORTOBJ + FILEDESC + FILETYPE for now. ISTM that gets it clean enough, and it can be revisited later if necessary. One thing that I think Peter referred to - libraries that we version (e.g. libpq) in standard Unix major.minor style should probably carry that version rather than the PostgreSQL version number. Aggh, I knew there was one more issue that needed resolving before I could move on :) This we can do, but it does two things: 1) We'll have to add extra code somewhere to have it pick SO_MAJOR_VERSION,SO_MINOR_VERSION in the cases where it is a shared library, and PG_VERSION_NUMERIC when it's an app. But this can probably be done in the rule in Makefile.global. 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 conversion procs are at 0.0, and they all build from the same rule. That means they all need to get bumped when one of them changes. That may be a good idea for unix platforms as well, but it is more work during releases that has to be included. Not sure if we want to buy into that? 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. //Magnus ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] win32 version info
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 software depends on. We might have to find some workaround for people who have installed dev versions, but we haven't made an official release yet, so those people are using it on a caveat emptor basis. I really think we need to get this right, and to do so from the start. The people who have installed the dev snapshot should expect these things to happen :-) I don't particularly care about those. I do care about the people who have installed previous versions. The client library have been available for a long time with this version numbering scheme. My vote is for sticking witht he 7.5.x etc version numbering for the win32 binaries. I think it's easiest, and that's what win32 programs generally do. And we can then continue the practice of not bumping version numbers of the unix shared libs until such a time we might want to change that behaviour (it might not even be necessary ever..). //Magnus ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] win32 version info
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 conversion procs are at 0.0, and they all build from the same rule. That means they all need to get bumped when one of them changes. That may be a good idea for unix platforms as well, but it is more work during releases that has to be included. Not sure if we want to buy into that? So far we haven't done any versioning on these because nothing checks their version. If you think that now something is going to check their versions, then we're going to have to do something about that. But what will happen if they stay at 0 indefinitely? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] win32 version info
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 build-time linkable DLLs, which really need a version, and leave it out for the rest. Clearly, we cannot put a version into every file anyway (headers files, etc.), so everything must have a version does not hold anyway, unless there is some weird rule again that certain things must have one. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] win32 version info
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 now is simply whether or not this versioning cruft justifies its existence, presumably for facilitating packaging and installation of binaries (particularly those that cannot report their version readily, such as DLLs). I personally certainly have no use for it, and I don't see us getting the Designed for Microsoft Windows tick any time soon, but I have no doubt that Magnus, in working on the win32 installer, is perhaps seeing the need in an entirely different light. Designed for Microsoft Windows :-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] win32 version info
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 into a single build rule somewhere? And surely we do not need to maintain a boilerplate .rc file for every executable. Finally, the patch adds an elephant icon to psql.exe (so it'll go nicely in the start menu for example). You need a lot better reason than that to convince me to put a binary file into CVS. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] win32 version info
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 error-checking purposes (which DLL version is really there? And debugger will also tell you which version of the DLL is actually loaded in the process working space if yo uhave more than one on your system), software distribution (all installers are required to check this field to make sure they don't overwrite a file with an older version), software inventory, the list goes on. Finally, the patch adds an elephant icon to psql.exe (so it'll go nicely in the start menu for example). This icon was taken from Gavin Roys postgresql artwork page (http://pgsql.gavinroy.com/art). Would it be possible to provide a scalable version of the logo in the source code and generate the appropriate format from that at build time? I know, for example, that some Linux packages put psql in their menu and might like an endorsed logo for that. If we used, say, SVG for that, we could also avoid storing more binary files in the source tree. (I have an SVG version of the elephant available, btw.) We could even provide a .desktop file. I have no idea, actually. I don't know of any software that will do this, but that certainly doesn't mean it exists. And I'm not enough of a graphics guy to comment on if there would be issues with the convert (quality-wise for example). Moreover, the file should be called psql.ico, not pgsql.ico. Well, it is a general pgsql icon :-) But yes, since it's in the psql directory it should probably be renamed. BTW, for those who aren't aware - this file is never actually installed along with the binary. It's statically linked into the binary at build time. //Magnus ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] win32 version info
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 think it's junk. But that's just me, I suppose (along with windows users, but we clearly don't care much about them). 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 product description in there which is the same). As for putting it in a single build rule - I don't know if that can be done. I thought it over and didn't come up with a way, but there may be other who are better at writing Makefiles... I guess a script could be written that generates the file, but the per-binary information has to be somewhere. Not sure how that method would be cleaner. Finally, the patch adds an elephant icon to psql.exe (so it'll go nicely in the start menu for example). You need a lot better reason than that to convince me to put a binary file into CVS. Well, if someone can come up with a way to build an icon and link it into the binary without any binary files, I'm all for it. We can of course do without it, but it does make the win32 look very unproffessional. I probably don't understand what the potential problems are with binary files in cvs, because I don't quite see the issue... //Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] win32 version info
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 product description in there which is the same). As for putting it in a single build rule - I don't know if that can be done. I thought it over and didn't come up with a way, but there may be other who are better at writing Makefiles... I guess a script could be written that generates the file, but the per-binary information has to be somewhere. Not sure how that method would be cleaner. We would not need to generate it at all. Maybe something like this would work: In the makefile, symlink each .rc file to the boilerplate version somewhere, and put a definition like this: FILEDESC=\whatever you like\ and also conditionally include the *rc.o file in its objects list. The rc file would, of course, have this line: VALUE FileDescription, FILEDESC Makefile.global or similar could define the build rule once, like %.o: %.rc windres -DFILEDESC=$(FILEDESC) $ -o $@ --include-dir=$(top_builddir)/src/include I hope you get the idea. cheers andrew ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] win32 version info
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 the process working space if yo uhave more than one on your system), OK, that should go into the DLL, just as it goes into shared libraries on Unix. But then you need to use the actual shared library versions that we use. software distribution (all installers are required to check this field to make sure they don't overwrite a file with an older version), software inventory, the list goes on. This is the packager's business, not ours. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] win32 version info
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 --version to? And it won't work for any DLLs. 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 the process working space if yo uhave more than one on your system), OK, that should go into the DLL, just as it goes into shared libraries on Unix. But then you need to use the actual shared library versions that we use. Um. Right. That goes on some things (like libpq). But all DLLs don't have that (seems plpgsql still claims 1.0, which can hardly be correct, for example. There has to have been *some* revisions to it since it was created...). But perhaps that should be fixed in the general shared lib version, then? The common way to do it on win32, if we want to follow that, is to have majorversion.minorversion.build.sub-build. Mapping that to the shlib would be more along the line of 7.5.shlibmajor.shlibminor. If we want to go down that path. software distribution (all installers are required to check this field to make sure they don't overwrite a file with an older version), software inventory, the list goes on. This is the packager's business, not ours. It's our business to make it *possible* for the packager, IMHO. And by not including version information, we make it impossible for someone to use the unpatched source tree to make a compliant installer for postgresql. And putting the responsibility on the packager still doesn't help for the inventory case. //Magnus ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] win32 version info
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, so that it's not necessary for the individual Makefiles to be explicitly aware of it at all ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] win32 version info
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] win32 version info
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 just the FILEDESC row in there? That would be ideal, but this is probably close enough if no one has a great idea about how to get rid of the manual addition to $(OBJS). 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... Yeah, that's not a bad idea. If anyone can think of plausible reasons why we might end up with other things needing to be built for every executable, it would be quite reasonable to go this route. 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. And the existing rules are diverse enough that it might be a real pain to construct such a pattern rule anyway. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] win32 version info
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 Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] win32 version info
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 existing rules are diverse enough that it might be a real pain to construct such a pattern rule anyway. ...is the problem. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] win32 version info
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 of a file is installed. For error-checking purposes (which Didn't you and Claudio disagree just a week ago when I asked for some Win32 C code to auto-check versions like initdb calling postgres? That was only in one C file ifdef'ed and you thought it was overkill. Now you want to put stuff in every binary directory? Seems inconsistent to me. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
