New run version with patches for Windows 7
Charles Wilson
cygwin@cwilson.fastmail.fm
Mon Aug 10 13:19:00 GMT 2009
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).
More information about the Cygwin-apps
mailing list