[ros-dev] rbuild auto generated resources

[Marc Piulachs]

>  From all changes introduced on my rbuild branch auto
> generated resources 
seems to be the most controversial by far so I will try to
explain here the
design decision behind it

 

One of my particular obsessions is trying to optimize and automate the
maxium ammout of things, if something can be reasonably created
automatically why do it by hand?

 

CURRENT SITUATION

=================

 

Currently the version common defines REACTOS_STR_FILE_DESCRIPTION ,
REACTOS_STR_INTERNAL_NAME and REACTOS_STR_ORIGINAL_FILENAME , localized
resources and theme manifest are added to [modulename].rc , rsrc.rc or
splitted between both.

 

Problems:

 

            - Theme manifests files "manifest.xml" are architecture
dependent (X86)

            - Duplicated content, we will have hundreds of identical
manifest files for every aplication

            - No way to compile an aplication without manifest

            - No way to compile an aplication with only specified
localizations

            - Duplicated work, rbuild has all the information required to
automatically generate the defines

            - If we decide to rename or introduce a new define in the future
we will have to edit all resources by hand.

            - Resource localizations are compiled with any control , the
only way to check if they are included is by hand.

 

Advantatges to my proposal:

 

            - It solve all the above problems.

            - Reduce man work 

            - Allows future changes in the format (editing the resource
generator source code (1 file) vs all resources files on SVN)

            - It's the base to other future enchancments , when a new
feature is added to rbuild we have just to modify it and all modules will
automatically inherit it.

 

An most important of all , it represents a change of the model to a metadata
oriented build process. You describe the content  (source code , resources
...) rather than the build , rbuild uses that information to generate the
apropiate image (as always) but this information can also be used for
multiple other things, analitics , reports , web ....

 

How does it work?

=================

 

First of all IT'S OPTIONAL , you can decide to use it or not, your choice.

 

We will use the eventvwr.rbuild as sample:

 

<?xml version="1.0"?>

<module name="eventvwr" type="win32gui"
installbase="system32"
installname="eventvwr.exe">

            <include base="eventvwr">.</include>

            <include base="eventvwr"
root="intermediate">.</include>

 

...

 

            <!-- Auto generated stuff -->

            <automanifest>manifest.xml</automanifest>

            <autoresource>auto.rc</autoresource>

 

            <!-- Authors -->

            <developer>mpiulachs</developer>

            <translator>cfinck</translator>

            <translator>fireball</translator>

            <translator>mpiulachs</translator>

 

            <metadata description="ReactOS Event Log Viewer" />

 

            <!-- Avialable localizations for this module -->

            <localization
isoname="de-DE">lang/de-DE.rc</localization>

            <localization
isoname="en-US">lang/en-US.rc</localization>

            <localization
isoname="es-ES">lang/es-ES.rc</localization>

            <localization
isoname="fr-FR">lang/fr-FR.rc</localization>

            <localization
isoname="ru-RU">lang/ru-RU.rc</localization>

</module>

 

to turn auto resources on we have to add the <autoresource> element with the
name of the resource that will be created in the INTERMEDIATE folder in this
case it will be named "auto.rc".

 

It will also automatically create the apropiate manifest.xml file for the
architecture being build (x86 or PPC) and will reference it in "auto.rc"

 

Also it will validate and include the localizations, even it has
localizations for 5 languages it will only compile those specified on
languages.rbuild

 

See attached files for autogenerated content

 

I tried to explain the motivation behind my changes and why I think they are
positive , of course I'm open to your questions , ideas or comments but
please be contructive and argument your point of view , "I don't like it ,
we won't use it" as someone said is not an expected opinion.

 

/Marc