Corinna Vinschen wrote: > Ok, so Alexander replied (thanks!) and would like to drop maintainership > so if you like to take it back, feel free.
OK. > We need run working for W7 asap, but in the long run, why not have both > capabilites in one single "run" application? Mainly to allow for continued mingw support by the simpler one. Here's what the README for run2 says: ------------------ Non-Cygwin (native win32/mingw) ports ============================================================================= run2.exe currently requires cygwin, but a more limited version (which supported only the Global::Target mode of operation) could easily be ported to native win32. [ed: or a full-featured MinGW port with the use of win32-pthreads and a native port of libxml; this approach would avoid SOME of the issues described below -- but what algorithm would mingw-run2 use to locate libXll.dll for dynamic loading/LoadLibrary?] While Patches are Thoughtfully Considered (PTC), I believe that such a modified version would require very ugly changes not only to the code, but also to the build machinery. This will only get worse once cygwin-1.7 specific features like support for (really) long filenames, Unicode/wide char XML contents, and wide char filenames, are added. Therefore, I believe -- and encourage -- a native-win32/ mingw-specific port to be implemented as a cooperative fork, or branch in the existing repository, rather than cluttering the code and build machinery with more #ifdefs and AM_CONDITIONALS. ------------------ So, creating a version of run2 that implemented strictly the functionality of the original run application -- or implementing a specific mode in run2 that exactly mimicked the operation of the original run application -- would be fairly straightforward. However, making that version/mode compilable under MinGW would not be; and in fact, I'd already given /that/ some thought, and decided that (1) it would require changes to the run2 that are Too Ugly For Words, and (2) that a fork of run2 for that purpose would be better. So...how many versions of run DO you want me to maintain <g>? Basically, supporting a native version of run2 myself -- in any form -- is not in my mission plan for run2 [*]. But, I believe it is part of the implied contract for the original run. So... Now, "in the long run", since a lot of the functionality is shared between run and run2, I could see merging development between them. Either by creating an API and (static) library containing most of the common functionality (e.g. the actual launch-target code, and some of the utility code, but not run's "magic guess-the-target-name from argv[0]" stuff nor run2's parse xml and probe for Xserver stuff). Or, explicitly sharing that code in source form a la' gnulib. In fact, it was with a view to these two possiblities that I said I "have a few ideas for refactoring" run. But, in whatever form, I think it best if run and run2 remain logically distinct, even long term. -- Chuck [*] Here's an idea for "long term" -- do the "fork" of run2 "for MinGW" as described originally -- one that would never "switch" between two targets nor probe for an Xserver by LoadLibrarying libXll.dll. It would still need mingw-libxml, tho. Then, add the "magic guess-the-target-name from argv[0]" from run. This "mingw" run2 fork, when compiled on cygwin, would basically then be a drop-in replacement for run, but with a (relatively) common source code, plus set-env-var-before-launching-target and xml-config support. This could be combined with the library/gnulib-style code sharing idea above (only, even more code would be common between the "original" run2 and the mingw/run-mimick version).
