Having worked with rbuild for a few weeks I have identified some problems
that would like to share. I also would like to hear the developers' opinions
about all of these issues because I want to start working to solving them.
A) The behavior of the "include" + "directory" tags are inconsistent when an
"include" is placed inside a "directory" for
example:
Correct: (expected : ke/i386/boot.S)
<directory name="ke">
<if property="ARCH" value="i386">
<directory name="i386">
<file
first="true">boot.S</file>
Incorrect: (expected : reactos/reactos.rbuild
real : reactos/reactos/reactos.rbuild)
<directory name="reactos">
<xi:include
href="reactos/reactos.rbuild" />
</directory>
should be:
<directory name="reactos">
<xi:include href="reactos.rbuild" />
</directory>
B) The "oldcrt" attribute is no longer used and can be removed.
C) The module types "Iso" , "LiveIso" , "IsoRegTest" and "LiveIsoRegTest"
are IMHO hacks introduced to be able use the makefile generation code.
rbuild is C++ so with a small code refactor they can be easly removed.
D) Any module is using the "EmbeddedTypeLib" module type , is really needed
or can be removed?
E) IMHO the "ElfExecutable" is incorrect . I posted my reasons some time
ago:
http://www.reactos.org/archives/public/ros-dev/2007-September/009770.htmlhttp://www.reactos.org/archives/public/ros-dev/2007-September/009771.htmlhttp://www.reactos.org/archives/public/ros-dev/2007-September/009779.html
F) The module type "alias" is only used for HAL related modules and IMHO it
isn't requiered because the problem it tries to
solve can be easly solved using "if" tags and conditional compilation.
http://www.reactos.org/archives/public/ros-dev/2007-September/009798.html
There are several reasons for this change:
- Currently every platform requires 3 new HAL modules. In the
future if new platforms are supported for example (X86 , XBOX , PPC , AMD64
, MIPS , IA64 , ARM ... ) 3 x 7 = 21 modules .. see what I'm saying?
- It simplifies backends work. No need to include logic for
alias handling.
- Conceptually wrong . every module represents a particular
functionality when you compile the module it should just reconfigure itself
to produce the appropriate image for the configured architecture .It a good
idea to have a true componentized operating system.
Regarding the ModuleType IMHO they should be used to provide information
that describes the module output/target not the build process! Iso , LiveIso
, Alias , ... all of them are meaningless they are not true metadata.
Long term enhancements:
X) tags like "linkerflag" or "compilerflag" are gcc/mingw specific and
should be replaced with other tags that provide the
equivalent functionality using a more abstract aproach so other
backends/compilers could benefit from it. rbuild files should
only describe the source code and the compilation process without including
specific information.
/Marc
speaking of resources, Alexandre is now allowing binary resources in
winehq git as it actually handles them in a sane way as opposed to
cvs. This means you guys can drop bin2res if your using it anywhere
and keeping shell32 resources in sync with Wine will be less of a diff
now.
Thanks
Steven
On 10/3/07, hpoussin(a)svn.reactos.org <hpoussin(a)svn.reactos.org> wrote:
> Author: hpoussin
> Date: Wed Oct 3 18:17:46 2007
> New Revision: 29378
>
> URL: http://svn.reactos.org/svn/reactos?rev=29378&view=rev
> Log:
> Add back windres, it is still used after wrc invocation
>
> Modified:
> trunk/reactos/Makefile
>
> Modified: trunk/reactos/Makefile
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/Makefile?rev=29378&r1=2937…
> ==============================================================================
> --- trunk/reactos/Makefile (original)
> +++ trunk/reactos/Makefile Wed Oct 3 18:17:46 2007
> @@ -298,6 +298,7 @@
> objcopy = $(Q)$(PREFIX_)objcopy
> dlltool = $(Q)$(PREFIX_)dlltool
> strip = $(Q)$(PREFIX_)strip
> +windres = $(Q)$(PREFIX_)windres
>
> # Set utilities
> ifeq ($(OSTYPE),msys)
>
>
>
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hello,
recently, different people raised a question: How should development
process evolve with time, when ReactOS has more (much more)
developers willing to contribute code?
There are many possibilities, however all of them assume more or less
an overhead, and need additional human resources.
I will outline one suggested method, and want you (developers) to
"constructively criticize it", improve it, or offer a better method.
Even if it involves changing current version control system, or
anything - suggest the method.
So, the suggestion I've already got is this:
Trunk is writable only by a so-called Integrator person (maybe a few
persons). Branches are writable by a big amount of developers.
Typical development process is as follows:
1. A developer creates a ticket in issue-tracking system (currently
Bugzilla), where he describes what's wrong and what his change fixes/
improves.
2. He creates a branch with a name BZ-XYZ (where XYZ is ticket's
number), and commits his changes there.
3. An integrator, daily, goes through all BZ-... branches, does svn
merge to trunk of each branch, test it, if no regression occurs, he
commits changes to trunk and svn deletes the respective BZ-... branch.
Some kind of integration system is definitely needed, so please avoid
fast answers like "Let's stay as we do now". Better approach is
needed, and I'm looking for it. If you can offer something - do so.
With the best regards,
Aleksey Bragin.
I considered that, but it's a bad idea. Try to remember what the hell
it was to merge changes into release branch ("stable"), done since
0.3.3-RC1 was released? And that was only to do a RC2, about 1-2
weeks, and complete hell to merge so it was decided that a rebranch
was easier (and in fact it worked very well).
WBR,
Aleksey Bragin.
On Oct 3, 2007, at 9:03 PM, Magnus Olsen wrote:
> Hi
> I think we should have something call stable trunk and devloping trunk
>
> The stable trunk getting all changes that are ready and stable and
> it will
> be
> the release version of trunk.
>
> the devloping trunk is where everyone working in
>
>
> But the main problem is we do not have any good tools for regress
> testing
> and we are missing testcase for each api. I am working at moment
> writing
> testcase for gdi32, I hope this will make lest gdi32 allot more
> stable at
> end
> then I will start making testcase for win32k later maybe for user32
> then start fixing the real bugs and implement things. or working with
> everthing same times. we should need a test kit for each api and
> test for evertging invaild param, pointers, and real data in all case
> I known it is not fun todo but that is what we need to make ReactOS
> more stable and less bugs. Testcase for everthing.
Herve suggests using a kind of a continuous integration system,
describing it this way:
* precommit hook
if commit not to trunk, abort precommit hook
create a REV-abc branch from trunk and do the commit here
* regularly
go through all REV-abc branches (increasing ABC numbers)
test it
if not, inform user or whatever that test failed and go to next branch
try to merge to trunk
if not, inform user or whatever that merge failed and go to next branch
commit to trunk
delete the branch
go to next branch
* pros:
devs and users will have new version to trunk once they are tested
devs and users only have to know trunk
* cons:
changes are not immediatly available for everyone, except in REV-abc
branch
On Oct 3, 2007, at 12:50 PM, Aleksey Bragin wrote:
> Hello,
> recently, different people raised a question: How should development
> process evolve with time, when ReactOS has more (much more)
> developers willing to contribute code?
I'm getting this error when posting/modifying a bugreport
Bugzilla has suffered an internal error. Please save this page and send it
to aleksey(a)reactos.org with details of what you were doing at the time this
message appeared.
URL: http://www.reactos.org/bugzilla/process_bug.cgi
There was an error sending mail from 'ReactOS.Bugzilla' to
'hpoussin(a)reactos.org':error when closing pipe to /usr/lib/sendmail:
SumatraPDF is a lightweight Win32 pdf viewer app
http://blog.kowalczyk.info/software/sumatrapdf/http://code.google.com/p/sumatrapdf/
The name "sumatra" sounds weird (for an app), so I renamed the
directory and the output exe file to "SmartPDF" (based on suggestions
from #reactos).
SumatraPDF comes with VS 2k5 project files.
I have fixed various compile issues so that libjpeg, poppler,
fitz/mupdf and sumatra app itself compile without errors in mingw
(RosBE 0.3.7.2 Win32).
All code changes can be found by grep/search for "@note:", I added a
comment to each changed code line.
The remaining problem is the linking issue. Currently it does NOT link
correctly.
Timo Kreuzer mentioned on 2007-09-27 in #reactos something that may be
related to the issue:
"it [sumatrapdf] imports a function from winspool.drv by number, when
you add that number to winspool.def, it starts"
Please have a look at it, fixes are appreciated :)
Klemens
Hi,
Alex nudged me in IRC about this, but sadly I've not quite figured this out
yet.
It appears my definitions for Kernel Streaming GUIDs are not quite right.
This results in ugly code like so:
--
const GUID foo_audio_category = STATIC_KSCATEGORY_AUDIO;
DoSomethingWithTheGuid(&foo_audio_category);
--
Which consequently results in a barrage of compiler complaints about brace
initialization.
It should be possible to just do:
DoSomethingWithTheGuid(KSCATEGORY_AUDIO);
I'm clearly going wrong somewhere in KS.H or KSMEDIA.H but to be honest am
blind to whatever is causing the problem.
If anyone can figure out what I'm doing wrong here, I'd appreciate it.
Thanks.
-Andrew