Re: [ros-dev] rbuild problems/suggestions

[Marc Piulachs]

Anyone wants to comment on this?

_____

From: Marc Piulachs [mailto:[e-mail]] 
Sent: Saturday, October 06, 2007 10:24 PM
To: '[e-mail]'
Subject: rbuild problems/suggestions

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.html

http://www.reactos.org/archives/public/ros-dev/2007-September/009771.html

http://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

[Colin Finck]

Hi Marc,

I talked with Hervé about this in IRC.
> Marc Piulachs wrote: 
> A) The behavior of the "include" + "directory" tags are inconsistent

He has no opinion about this directory thing.
But I myself would prefer your change here, so we have a consistent
handling.
> B) The "oldcrt" attribute is no longer used and can be removed.

Hervé agrees with you on that.
> C) The module types "Iso" , "LiveIso" , "IsoRegTest" and
> "LiveIsoRegTest" are IMHO hacks introduced to be able use
> the makefile generation code.

They are hacks, but they are still needed.
If you can rewrite them better, feel free to do so :-)
> D) Any module is using the "EmbeddedTypeLib" module type , is really

needed or can be removed?

This module is needed for a future import of "stdole2.tlb".
> E) IMHO the "ElfExecutable" is incorrect

We cannot say anything about that, you should sort this out with Art Yerkes.
> 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

This would really require much work and mingw is the only backend, which is
currently used for compiling ReactOS. Some of the stuff, which can be
compiled with MSVC, will be compiled in the IDE with the project files.
But generally this sounds good, so we can think about that as a long-term
plan.

Generally, if you have a great idea to improve something, don't hesitate to
write a patch and file a bug in our Bugzilla for it :-)

Regards,

Colin

[Marc Piulachs]

> > E) IMHO the "ElfExecutable" is incorrect
> We cannot say anything about that, you should sort this out with Art

Yerkes.

Will try to contact Art directly.
> > 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
> This would really require much work and mingw is the only backend, which is
> currently used for compiling ReactOS. Some of the stuff, which can be
> compiled with MSVC, will be compiled in the IDE with the project files.
> But generally this sounds good, so we can think about that as a long-term
> plan.

Ummm , actually when you compile any ros module with the MSVC IDE you are
really facing this problem. The msvc generated project files are created by
the msvc backend interpreting the rbuild files. When it finds an embedded
mingw specific compiler or linker flag it has to "translate" it to the msvc
equivalent which is neither practical nor elegant.
> Generally, if you have a great idea to improve something, don't hesitate to
> write a patch and file a bug in our Bugzilla for it :-)

Yep, the problem is that patches sent to bugzilla usually takes days or even
weeks to be applied what leads to having to maintain multiple working copies
to avoid conflicts can I request a branch to store my changes?

Regards,
/Marc

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev