Thread: win32 version info - try 2
Here's another attempt at adding version info to win32 stuff. Lots of changes since last try :-) * Build rules in Makefile.global builds the .o or .rc file required. Each makefile defines PGFILEDESC with a file description that gets imported. * Full version number is pulled from pg_config.h. The numeric-only version number is just in win32ver.rc - I notice the release instructions have manual editing of the other rc file already, so it's not that much more work. It can easily be changed by adding to configure, but I'm not sure it's worth the job now that there is just one place that would use it. * Versioninfo not set on all DLLs, just the ones that would normally be linked against client programs. I'd still like to see it on more, but it's not *that* important. It could easily be added using the same rules if we wanted to. It still uses the 7.5.x.y version number notation, since for now it only affects pgevent.dll which is win32 only anyway and doesn't have a version number of its own. * Just two files to add - both go in src/port. (Moved the icon there per discussion on IM with Bruce) * A makefile can set PGAPPICON=<iconname> to specify an icon to be linked in. (I don't know how icons work on other platforms, this could perhaps be extended to others?) //Magnus
Attachment
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/
>> * 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
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/
>> 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
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 <mha@sollentuna.net> 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 >
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)