timo.kreuzer at web.de
Mon Mar 9 07:12:13 CET 2009
Hahaha, love it ;-)
I understand it like this:
"It's shit atm, even with everything I tried it stays shit. So whatever
you do it will always stay shit. It's natural born shit. Shit for life.
Goddam shit even."
"Changing it won't work, because it doesn't work already and we already
do it like that so we don't actually change anything. So you better not
change it as changing it won't change anything."
You only ignored that you don't even have to sync every fckng sdk
change. Do you update rosapps after every commit? Everytime you update
reatcos? Probably not. Probably only when something doesn't compile anymore.
Choose for yourself to update your sdk and rebuild everything or don't
The fucking idea behind seperating it. Independency.
It might also keep people from randomly updating the sdk as long as it's
not needed, or it could well be done in a branch that can be synched
once a month or as soon as any change is really neccessary for other
The suggested solution is about making independency more natural, more
apparent, more concrete, more controllable than the current "I trust in
rbuild" solution, that obviously leads to nowhere.
btw, rbuild and the other build tools could be seperated, too. So you
also have the choice to sync the goddam rbuild changes or not.
I don't know if a "goddam itemized list" will solve any problem, but it
feels good to have talked about it....
It's about splitting things that get too large, outsourcing,
abstraction. It's natural, evolutional.
> Timo Kreuzer wrote:
>> I think it would be better to seperate the components from each other as
>> much as possible and only compile the modules that have been changed.
> It doesn't work. And you know why? because it's already implemented. And
> it doesn't work. People fuck with the SDK all the time. They piggyback
> SDK changes on two-liner commits, amplifying the two lines millionfold
> into a cascade of useless recompilations and relinkings. They sync Wine
> modules every time Alexandre Julliard so much as farts in their general
> direction, making sure to pick all the goddamn modules with public IDLs,
> which results in an SDK rebuild, which results in rebuilding 99% of the
> tree because an attribute that was previously unimplemented in rpcrt4
> was uncommented in a bumfuck IDL somewhere. When you call out people on
> this shit, "but syncing every point-point Wine release is _important_"
> is the usual defense, and you can't argue with meatheaded truisms (in
> fact, my plan is to slowly commit the rug from under them, but that
> takes time)
> Nobody gives a flying fuck about this. Try "full dependencies" some time
> (add -df to the rbuild command line), only do incremental builds for a
> week or two, and become frustrated at SDK retardation in an _informed_
> way when you get a string of a half dozen near-full rebuilds after you
> have gotten used to 5-minute incremental builds, and absolutely nobody
> sees an issue with it because the build server has a trillion cores and
> a quintillion terabytes of RAM
>> We could try to split the current reactos tree into seperate trees,
>> maybe like this:
> Oh how I _love_ itemized lists. Seems the solution to humanity's every
> problem has to start with a goddamn itemized list
> Ros-dev mailing list
> Ros-dev at reactos.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ros-dev