12 Jun
2006
12 Jun
'06
9:20 p.m.
I'm answering to ros-dev so all developers could share their point of
view (Klemens' original email is attached below).
As I basically outlined in an irc conversation, there are 3 possible
ways for us to sync with the Wine project:
1) Do manual syncs (the current way), keeping their code in our tree,
building with our build system
2) Do auto-import of their source code into our tree, plus
automatically detect changes in their build files and propogate them
to our .rbuild files
3) Do binary-syncing of the dlls which are free from reactos and wine
hacks, and do manual syncs for dlls which are forked (like setupapi
which is better implemented, directx dlls which are partly shared and
partly implemented differently, etc).
However, it was not possible to easily come to a solution what to do.
I will give a small overview of all ways:
1) We lag behind, providing outdated, featureless and buggy version
of dlls. And even more, we depend on dlls bugs, reactos hacks in
them. Syncing them requires time and constant efforts.
From the good side we have absolute control over the libraries - we
can enable/disable debug messages, build them for different
architectures, optimize for different CPUs etc
2) This could sound like an ideal way, because it keeps advantages of
1. plus removing disadvantages of having to waste time doing syncs.
However conversion from Wine's build system makefiles to ReactOS's
build system .rbuild isn't trivial. Plus developing an auto-syncer
between Cvs/Git and our SVN doesn't look like an easy task too.
3) Reduces compilation time, however wine dlls are built on another
server, and just downloaded during build process (or kept in SVN
server in binary form). It'd be needed to adjust building mechanism
to be able to produce other platform binaries. Updates will be
"heavy" (but initial download smaller).
I'm listening to your (all ReactOS and Wine devs) comments, and
probably I will write answers to Klemens' email later.
WBR,
Aleksey Bragin.
On Jun 12, 2006, at 2:35 PM, Klemens Friedl wrote:
Hi Aleksey,
I spoke with Gé and he explained me the vendor import process in
short. As soon as I find some time I will try out it myself and update
the Wine libs in our SVN tree, if you don't mind.
Or do you want to switch to a binary wine files in trunk anyway?
I will try to update Wine files about every months after the first
time, if that is okay. The changes of wine 0.9.x of every two week are
minor things so, every months should be fine. sdwards mentioned that
timeframe too, as we discussed about that topic about one week ago on
#winehackers and #reactos (the first time).
btw. Gé mentioned there ARE reasons why our Wine libs DO differ from
WineHQ's one. Well Gé is not a ros dev anymore but he had not done the
vendor import work and maintain all the changes for fun, it's
important to have our adjustments in there.
Imagine for example all icons would got lost.
Wine does use Unix specific functions like "unixfs" in several libs,
the sound libs will get a lot different in near future too
(silverblade is working in this area) and several directx libs. So a
quick auto vendor import won't work anyway.
In my opinion, the binary idea is not worth any efford:
In my opinion, binary files on in a svn dir is a very bad solution.
You cannot view the source and commit the changes, you have to
download all binary files every time (every 2 weeks), binary files are
not portable, etc.
The advantages of source code is in addition to the oposite of the
facts above that you have to download only the diffs of the file
changes (svn client does that for you) and that have everything
(source) on your local hdd.
Sure the build-time would decrease about 10-15% if we use binary
files, but i don't bother about 15% time.
And please shift the wine lib conversation to ros-dev(a)reactos.org.
The irc chat is not suitable for such a discussion where more than 3-4
devs are involved. It is not possible to answer to more then one msg
the same time. And while you write, several other persons post other
msg's.
Mailing lists does have a purpose and does make sense here!
E-Mail's are written in a better english, no short abbreviations, etc.
and the devs does think a bit longer about what the write (no offence
here!).
Best regards,
Klemens