Hello, there are a few ideas I would like to get feedback about:
1) iBrowser. Do we need it nowadays in the tree, when we have firefox working? 2) In order to slightly decrease a load to our build servers, Alex proposes to build Debug version without any optimizations at all, thus increasing compilation speed. For regression testing, release builds should be used, since release builds are the most sensitive to possible errors. 3) RBuild improvement - the "components bundles" concept should be (re)introduced: if I type "make <directory name>", I would like to get all components inside that directory to be built. 4) Dependency map of ReactOS - maybe this should be implemented inside of RBuild too. Dependency map is a tree, which shows how modules depend from each other. Fortunately, we don't need to do this by hand, since we can use rbuild's parsers/etc. Output format of the map - open for suggestions.
If someone feels he is able to do point 3 or 4 - this is greatly appreciated, and will help development of ReactOS.
With the best regards, Aleksey Bragin.
On 12/13/06, Aleksey Bragin aleksey@studiocerebral.com wrote:
Hello,there are a few ideas I would like to get feedback about:
- iBrowser. Do we need it nowadays in the tree, when we have firefox
working?
If we can fix it's bugs (like form input), I say keep it. Otherwise drop it. I'd like to see getfirefox also removed and have FF added to packmgr.
- In order to slightly decrease a load to our build servers, Alex
proposes to build Debug version without any optimizations at all, thus increasing compilation speed.
I'd like to see the iso archive consistent. Maybe we need more buildservers so we can build more configurations?
For regression testing, release builds should be used, since release builds are the most sensitive to possible errors.
... and produce the least amount of debugging output.
- RBuild improvement - the "components bundles" concept should be
(re)introduced: if I type "make <directory name>", I would like to get all components inside that directory to be built.
++
- Dependency map of ReactOS - maybe this should be implemented
inside of RBuild too. Dependency map is a tree, which shows how modules depend from each other. Fortunately, we don't need to do this by hand, since we can use rbuild's parsers/etc. Output format of the map - open for suggestions.
Unless it can generate a very detailed map, I think it should be done by hand, possibly as punishment for breaking build/boot. ;0)
WD
WaxDragon wrote:
On 12/13/06, Aleksey Bragin aleksey@studiocerebral.com wrote:
Hello,there are a few ideas I would like to get feedback about:
- iBrowser. Do we need it nowadays in the tree, when we have firefox
working?
If we can fix it's bugs (like form input), I say keep it. Otherwise drop it. I'd like to see getfirefox also removed and have FF added to packmgr.
What's the point of keeping it? Even Vista doesn't have a built-in browser anymore. It was only created back then ffox didn't work. I think we should instead include our own mshtml.dll which does the same trick as WINE and uses the mozilla engine, and have a simple C stub browser that just uses the library. But until then ibrowser is a C++ hog.
- In order to slightly decrease a load to our build servers, Alex
proposes to build Debug version without any optimizations at all, thus increasing compilation speed.
I'd like to see the iso archive consistent. Maybe we need more buildservers so we can build more configurations?
Maybe someone can finally start a donation fund to Christoph so he can buy new servers and/or upgrade them...it's been promised to me for ages.
- RBuild improvement - the "components bundles" concept should be
(re)introduced: if I type "make <directory name>", I would like to get all components inside that directory to be built.
++
++++++++++++++++++++++++++++++++++++++++++.
- Dependency map of ReactOS - maybe this should be implemented
inside of RBuild too. Dependency map is a tree, which shows how modules depend from each other. Fortunately, we don't need to do this by hand, since we can use rbuild's parsers/etc. Output format of the map - open for suggestions.
Unless it can generate a very detailed map, I think it should be done by hand, possibly as punishment for breaking build/boot. ;0)
Doing it by hand means someone would update it each time we make a chance. The map should only be a tree... basically I want to identify orphaned components, under-used components etc. I forsee the day when we'll start importing 3rd-party libs like crazy and unless we're careful it'll destroy the tree.
On Wed, 2006-12-13 at 15:19 -0500, WaxDragon wrote:
On 12/13/06, Aleksey Bragin aleksey@studiocerebral.com wrote:
Hello,there are a few ideas I would like to get feedback about:
- iBrowser. Do we need it nowadays in the tree, when we have firefox
working?
If we can fix it's bugs (like form input), I say keep it. Otherwise drop it. I'd like to see getfirefox also removed and have FF added to packmgr.
Having FF by default would make life easier, especially when testing without a network connection (whyever that may be). I don't think I've ever tried to use iBrowser for any length of time, but when I do, I think it needs a lot of looking after.
- In order to slightly decrease a load to our build servers, Alex
proposes to build Debug version without any optimizations at all, thus increasing compilation speed.
I'd like to see the iso archive consistent. Maybe we need more buildservers so we can build more configurations?
For regression testing, release builds should be used, since release builds are the most sensitive to possible errors.
... and produce the least amount of debugging output.
As a tester; I like debug output... but if you insist... :)
- RBuild improvement - the "components bundles" concept should be
(re)introduced: if I type "make <directory name>", I would like to get all components inside that directory to be built.
++
++^2
- Dependency map of ReactOS - maybe this should be implemented
inside of RBuild too. Dependency map is a tree, which shows how modules depend from each other. Fortunately, we don't need to do this by hand, since we can use rbuild's parsers/etc. Output format of the map - open for suggestions.
Unless it can generate a very detailed map, I think it should be done by hand, possibly as punishment for breaking build/boot. ;0)
I don't see why it shouldn't. I forget what the GNOME system is called, but the maps it produces are incredibly useful and detailed.
-
Aleksey Bragin -
Alex Ionescu -
Toby Smithe -
WaxDragon