Mathias Michaelis <[EMAIL PROTECTED]> writes: >> I'd suggest at least removing these two copies >> > Here is my answer: Version 0.6.1 of the GetGnuWin32 package doesn't > copy this two files anymore. Furthermore, it now first checks if a > file already exist and if yes does not overwrite it.
That's excellent news - I'm fairly sure this will solve more problems than it creates. > And yes, update-links.bat is optional. I guess this is in the new version - in the version I have, install.bat calls update-links.bat, so I have to edit install.bat to skip update-links.bat. I'll get the new version soon, and try it. > I encountered much other problems with gnuwin32. E.g. file.exe from > the file-4.13 package brings its own rxspencer.dll (within > file-4.13-dep.zip) that is not compatible with that one from the > regex-spencer-3.8.g.3 package. As a consequence, the regex- > spencer-3.8.g.3 package is now listed in the EXCLUDE.TXT file. I agree - this was certainly a major problem in the past. It's improved a lot recently, but there are odd packages which have not been updated for a long time, which still have problems. > Another, yet very big problem is that each package must > theoretically be installed in its own directory which path name is > hard-wired within the executables. This however would lead to an > explosion of the amount of gnuwin32 directories. > > Therefore my GetGnuWin32 scripts extracts all packages in the same > directory tree (that later can be copied e.g. to %ProgramFiles%\gnu- > win32). This seems to lead to an accidental mixture of new and old > dlls. Also, the programs don't find their configuration data in the > .../etc directory. > > I think it would be a big improvement when the gnuwin32 binaries > would have the following properties: > > 1. Only relative path names that refer to a %GNUWIN32% main > directory are hard-wired within the executables and dlls. This > main directory is, as denoted, defined by an environment > variable. In actual fact, it is possible to make all paths relative to the location of the executable - that is (I believe) what newer GnuWin32 programs do. With this approach, there is no need for an environment variable at all. > 2. Every binary (.exe and .dll file) has a VERSIONINFO Resource > Header. If then a binary that already exists in the > %GNUWIN32%\bin folder is extracted again from some new downloaded > package, one can check the version before overwriting the already > existing file. > > Of course the file version could also be appended to the file > name as in name-version.dll, where 'name' must not match the > regular expression -[[:digit:]] while 'version' must begin > with a [[:digit:]], but I think this would be a minor solution. I'm not sure how this would help. Ultimately, people shouldn't create two DLLs with the same name but different behaviour. Annoyingly, they do, and there's not much we can do about this :-( Probably the best approach is what the GnuWin maintainer does with libintl and libiconv, which is to add -version to the name. This is better than the VERSIONINFO approach, as it allows different versions to coexist (but it should only be used when there really are problems, as otherwise upgrades are a nightmare). I'd say the GnuWin32 maintainers are doing a great job of handling a bad situation, and your package does a great job of what it does. The problems come from the original code, and we just have to work around them as best we can. Thanks again for your efforts, Paul. -- Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. -- Jamie Zawinski ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ GnuWin32-Users mailing list GnuWin32-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnuwin32-users
