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

[Ged]

My only concern is Visual Studio
Whatever you do, you must make sure all projects are able to be fully 
loaded by Visual Studio 2005/2008 without the interaction of rbuild.
As one of the hopes is to make everything in ROS VS compatible and 
buildable by Visual Studio, I would consider anything moving away from 
this a regression.

Ged.

Marc Piulachs wrote:
> 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
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Marc Piulachs]

Hi Ged,

I already had it present, actually there are two possible ways to solve it
As all automatic resources will be also re-created by the MSVC backend the
msvc generated project can reference the automatically created resource file
from the intermediate directory. The other solution is generate them on the
same folder as the also generated msvc project and add a svn-ignore to keep
them in the working copy. In my opinion the first solution is better as we
should keep the code base as clean as possible and move all generated
content to intermediate.

/Marc

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Ged
Sent: Friday, November 09, 2007 7:37 PM
To: ReactOS Development List
Subject: Re: [ros-dev] rbuild auto generated resources

My only concern is Visual Studio
Whatever you do, you must make sure all projects are able to be fully 
loaded by Visual Studio 2005/2008 without the interaction of rbuild.
As one of the hopes is to make everything in ROS VS compatible and 
buildable by Visual Studio, I would consider anything moving away from 
this a regression.

Ged.

Marc Piulachs wrote:
> 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
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

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

[Magnus Olsen]

I am usinf visual studio 2003 for I own 5 licen for it.
so all vs project must eb avail on build with all version of vs
and I am against adding  rc file to rbuild like he sugest.
I dislike that idea complete

----- Original Message ----- 
From: "Ged" [e-mail]
To: "ReactOS Development List" [e-mail]
Sent: Friday, November 09, 2007 7:36 PM
Subject: Re: [ros-dev] rbuild auto generated resources
> My only concern is Visual Studio
> Whatever you do, you must make sure all projects are able to be fully
> loaded by Visual Studio 2005/2008 without the interaction of rbuild.
> As one of the hopes is to make everything in ROS VS compatible and
> buildable by Visual Studio, I would consider anything moving away from
> this a regression.
>
> Ged.
>
> Marc Piulachs wrote:
> > 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
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Alex Ionescu]

I think you're all missing the point.

As it stands now, MSVC won't even READ most of your resource files  
because you've decided to write them in a way that violates the .rc  
standard and that only binres/windres/whatever-you-call-that- 
incompatible-garbage can parse.

Mark's proposal, apart from fixing all the problems he brought up,  
will finally allow you to write resource files that both MSVC and  
your-retarded-rc-compiler-name-goes-here can understand, with minimum  
effort. Right now, you're all stuck rewriting all your .rc files and  
creating .msvc.rc files.

By the way Mark, you should extend this to definition files. Once  
again, MSVC is incompatible with all the ReactOS .def files, which  
have been tailored so that Mangle32-gcc can understand them, so  
you'll have to create msvc.def files as well.

The more rbuild can generate independently, the better. You get MSVC  
files *after* running "make msvc8", and it's that step that would be  
creating the .def/.rc files for MSVC anyway -- what exaclty is it all  
you're complaining about regarding "MSVC" compatibility? You don't  
have it, how the hell can you lose it, and more importantly, why is  
the only suggestion that will finally let you have it "disliked"?!

You make no sense.

--
Best regards,
Alex Ionescu

On 9-Nov-07, at 1:59 PM, Magnus Olsen wrote:
> I am usinf visual studio 2003 for I own 5 licen for it.
> so all vs project must eb avail on build with all version of vs
> and I am against adding  rc file to rbuild like he sugest.
> I dislike that idea complete
>
> ----- Original Message -----
> From: "Ged" [e-mail]
> To: "ReactOS Development List" [e-mail]
> Sent: Friday, November 09, 2007 7:36 PM
> Subject: Re: [ros-dev] rbuild auto generated resources
> > My only concern is Visual Studio
> > Whatever you do, you must make sure all projects are able to be fully
> > loaded by Visual Studio 2005/2008 without the interaction of rbuild.
> > As one of the hopes is to make everything in ROS VS compatible and
> > buildable by Visual Studio, I would consider anything moving away  
> > from
> > this a regression.
> >
> > Ged.
> >
> > Marc Piulachs wrote:
> > > 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
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Marc Piulachs]

Hi Alex,
> By the way Mark, you should extend this to definition files.

It's a good idea, at the end I would like to remove the maximum possible
amount of gcc specific things. For example we currently have <compilerflag>
and <linkerflag> the content of this elements is just a meaningless string
(from a metadata point of view) that gets appended to the compiler/linker
command line, it works but if we seriously want to archive msvc
compatibility we should get ride of this way of doing things and start to
describe it in a "compiler agnostic" way that every backend can turn on
compiler equivalent switch (if support for that feature exists). MSVC
backend shouldn't depend on mingw backend as currently happen.
> The more rbuild can generate independently, the better. You get MSVC  
> files *after* running "make msvc8", and it's that step that would be  
> creating the .def/.rc files for MSVC anyway

You have summarized the idea pretty well, .rcs , .defs , ... are at the end
a particular way to store information, if we convert that information to a
more abstract and normalized format rbuild can generate back the information
in any format we may require with ease.

Regards,
/Marc

On 9-Nov-07, at 1:59 PM, Magnus Olsen wrote:
> I am usinf visual studio 2003 for I own 5 licen for it.
> so all vs project must eb avail on build with all version of vs
> and I am against adding  rc file to rbuild like he sugest.
> I dislike that idea complete
>
> ----- Original Message -----
> From: "Ged" [e-mail]
> To: "ReactOS Development List" [e-mail]
> Sent: Friday, November 09, 2007 7:36 PM
> Subject: Re: [ros-dev] rbuild auto generated resources
> > My only concern is Visual Studio
> > Whatever you do, you must make sure all projects are able to be fully
> > loaded by Visual Studio 2005/2008 without the interaction of rbuild.
> > As one of the hopes is to make everything in ROS VS compatible and
> > buildable by Visual Studio, I would consider anything moving away  
> > from
> > this a regression.
> >
> > Ged.
> >
> > Marc Piulachs wrote:
> > > 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
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

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

[Colin Finck]

Alex Ionescu wrote:
> As it stands now, MSVC won't even READ most of your resource files  
> because you've decided to write them in a way that violates the .rc  
> standard and that only binres/windres/whatever-you-call-that- 
> incompatible-garbage can parse.

Can you give me an example for such a resource file?

I successfully compiled cacls, calc and taskmgr including the resource files
with MSVC 2005.
They all use slightly different syntaxes, but I didn't see a resource file
yet, which completely fails under MSVC.

I agree that there are some resource files, which use unsupported language
ID's like LANG_WALON, but we could just leave them out or add an #ifdef
here.

Anyhow, I agree with enabling rbuild to generate more stuff automatically as
long as this doesn't break the already existing parts of MSVC compatibility
(yes, some minor user-mode stuff can really be compiled successfully with
MSVC).

Regards,

Colin

[Alex Ionescu]

Try ntoskrnl's  .rc file.

--
Best regards,
Alex Ionescu

On 9-Nov-07, at 4:29 PM, Colin Finck wrote:
> Alex Ionescu wrote:
> > As it stands now, MSVC won't even READ most of your resource files
> > because you've decided to write them in a way that violates the .rc
> > standard and that only binres/windres/whatever-you-call-that-
> > incompatible-garbage can parse.
>
> Can you give me an example for such a resource file?
>
> I successfully compiled cacls, calc and taskmgr including the  
> resource files
> with MSVC 2005.
> They all use slightly different syntaxes, but I didn't see a  
> resource file
> yet, which completely fails under MSVC.
>
> I agree that there are some resource files, which use unsupported  
> language
> ID's like LANG_WALON, but we could just leave them out or add an  
> #ifdef
> here.
>
> Anyhow, I agree with enabling rbuild to generate more stuff  
> automatically as
> long as this doesn't break the already existing parts of MSVC  
> compatibility
> (yes, some minor user-mode stuff can really be compiled  
> successfully with
> MSVC).
>
> Regards,
>
> Colin
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Colin Finck]

Alex Ionescu wrote:
> Try ntoskrnl's  .rc file.

Tried it and the "only" problem in this file is the Message Table.
RC only accepts a .mc file as a message table, windres/wrc needs them in an
own .rc file.

Anyway, I got it to build with both MinGW and MSVC this way:

#ifdef __GNUC__
#include "bugcodes.rc"
#else
1 MESSAGETABLE "ntoskrnl.mc"
#endif

But you're right, a true resource compiler, which completely supports the RC
syntax would be better here.

Regards,

Colin

[Ged]

Alex Ionescu wrote:
> what exaclty is it all  
> you're complaining about regarding "MSVC" compatibility? You don't  
> have it, how the hell can you lose it, and more importantly, why is  
> the only suggestion that will finally let you have it "disliked"?!
>
> You make no sense.

If you're refering to me, then you didn't read my mail.
I wasn't complaining about anything, I was simply asking for continued 
or improved msvc compatability.

Ged.

[Klemens Friedl]

About the rbuild proposal:

In my opinion, it's not the right way to go.
> From my point of view, the api and status generation tool (be it a

script or executable written in a common script language like perl,
php, python or C/C++) should parse the source code and gather all
information out of the original files.
It's neither necessary nor smart to store un-synced redundant metadata
in external files about the same.
the parser simply collect the data out of the source files.
I am under the impression that some want to try to add additional
metadata to files like *.rbuild files, just to simplify the parsing
process but on the otherside 'generate' a lot more problems by make it
almost impossible to keep the data in-sync.
> From a limited first point of view, it sounds great; but it reminds me

of one who is new to object oriented world and want to express
everything as object or metadata.
The real world is different, and it's better to keep it simple and let
the parser do its task => parse the source files. Don't get me wrong,
metadata are good and have it's place, but we have to make sure that
we keep the balance and avoid "information"-hell.

So instead of outsource the information (developer, translator,
language-info, etc.) from the source code to external rbuild files,
keep the data in place where it belongs to.
It's the parsers job to parse the source and extract it, and put it
together in a meaningful way (generate static output, be it xml or
html).

And as response to the rbuild package discussion:
The whole discussion about the language and package support has gone
in the wrong direction. It would be already possible to use rbuild xml
files to define the BootCD, LiveCD with some extra work (replace the
bootdata config files, with xml rbuild files and modify some setup
code; or alternative generated the bootdata files based on xml
config).
The main point is that the package information should be stored in a
single directory e.g. boot/bootdata, instead of adding such
information to each module-rbuild-file.
Having a single location, it would be a piece of cake to "fork"
compilation packages (BootCD, LiveCD) and create a custom ISO file by
copy&paste&modify the package xml file.
Of course something for the future, our current solution is fine for now.

Additionally, I would like to point out that the statistics and/or
API-docu tool should work fine on Win32 and Unix and be licensed under
a GPL v2+ compatible license. So that we can put it in place to our
online services (website).
Furthermore, Java and dotNet (C#, VB.Net, F#, etc.) should be avoided
(IMHO) for several reasons (either not-available, or too much overhead
and nowhere included by default; which is pretty much the opposite of
our ReactOS and especially the RosBE philosophy.

Klemens

[Marc Piulachs]

Hi Klemens, a few comments under your own lines:
> It's neither necessary nor smart to store un-synced redundant metadata
> in external files about the same.
> the parser simply collect the data out of the source files.

If you can say "un-synced redundant metadata" is that you haven't got the
idea yet. Actually parsing is the wrong way to go , is complicated , takes a
lot of resources , is slow and error prone , parsers exists because we live
in a un normalized world. Why do you think RDBS or metadata were invented
for?
> I am under the impression that some want to try to add additional
> metadata to files like *.rbuild files, just to simplify the parsing
> process but on the otherside 'generate' a lot more problems by make it
> almost impossible to keep the data in-sync.

If this "some" is me, as I already said you parsing is not the problem, It
has nothing to do with it. It has to do with normalizing and organizing the
information we already have in the more correct possible way. As I already
said multiple times I'm trying to describe the information contained on the
SVN (sources , languages ..) in the most abstract and neutral possible
manner so we can create more powerful tools that as a side effect automate
the most possible amount of things.

Please can you take a few seconds to think and answer me what's the
difference between <file>source.c</file> and <localization
isoname="en-US">en-US.rc</localization>? Exacly none.
> So instead of outsource the information (developer, translator,
> language-info, etc.) from the source code to external rbuild files,
> keep the data in place where it belongs to.
> It's the parsers job to parse the source and extract it, and put it
> together in a meaningful way (generate static output, be it xml or
> html).

In my opinion is just the opposite, move the information where it really
belongs, when you talk about a developer or a translator working in a piece
of code you refer them in a particular context , in this case a whole
module, the same for mantainers or translators , they are global to the
module.

Once again, the data extracted from parsing is not TRUE metadata just
meaningless strings that you can guess or interpret : "author : jdoe" ,
"author : jhondoe" , "author : jhon doe" are 3 different persons and
<author>Jhon Doe</author> just one , I think it's obvious.
> And as response to the rbuild package discussion:
> The whole discussion about the language and package support has gone
> in the wrong direction. It would be already possible to use rbuild xml
> files to define the BootCD, LiveCD with some extra work (replace the
> bootdata config files, with xml rbuild files and modify some setup
> code; or alternative generated the bootdata files based on xml
> config).
> The main point is that the package information should be stored in a
> single directory e.g. boot/bootdata, instead of adding such
> information to each module-rbuild-file.
> Having a single location, it would be a piece of cake to "fork"
> compilation packages (BootCD, LiveCD) and create a custom ISO file by
> copy&paste&modify the package xml file.
> Of course something for the future, our current solution is fine for now.

I think you have a small confusion here, the bootstrap module (btw It has
already been there for more than a year I only slightly modified it) has
nothing to do with packages, It is used to place the required files (dlls ,
exe , sys , etc..) that are required to boot reactos from a bootcd.As I
already explained I only removed the hardcoded "reactos" folder on the CD to
an architect based one (i386 on a IA32 build, PPC on a PowerPC build , ...)
no more no less.

I would suggest to take a deeper look at my code/changes so we can have a
more productive discussion, would be glad to answer and clarify all your
questions.

Regards,
/Marc

[Timo Kreuzer]

Marc Piulachs schrieb:
> Please can you take a few seconds to think and answer me what's the
> difference between <file>source.c</file> and <localization
> isoname="en-US">en-US.rc</localization>? Exacly none.

I agree in this point. It's just a logical step to do it this way.
> > So instead of outsource the information (developer, translator,
> > language-info, etc.) from the source code to external rbuild files,
> > keep the data in place where it belongs to.
> > It's the parsers job to parse the source and extract it, and put it
> > together in a meaningful way (generate static output, be it xml or
> > html).
>
> In my opinion is just the opposite, move the information where it really
> belongs, when you talk about a developer or a translator working in a piece
> of code you refer them in a particular context , in this case a whole
> module, the same for mantainers or translators , they are global to the
> module.
>
> Once again, the data extracted from parsing is not TRUE metadata just
> meaningless strings that you can guess or interpret : "author : jdoe" ,
> "author : jhondoe" , "author : jhon doe" are 3 different persons and
> <author>Jhon Doe</author> just one , I think it's obvious.

I disagree here. IMO information about developers and translators belong
to svn. They should neither go into the sources nor into rbuild files.
If you want to find out about it, ask svn and it will tell you the exact
name. We also don't really have maintainers for most modules, so most
rbuild files would be spammed with the names of lots of developers
without saying anything about who wrote a paticular piece of code.

Regards,
Timo

[Magnus Olsen]

authure names 
Marc Piulachs  have u heard about svn blame 
it review which person wrote a special file and which line that
person have done a change. 
  ----- Original Message ----- 
  From: Timo Kreuzer 
  To: ReactOS Development List 
  Sent: Sunday, November 11, 2007 11:56 PM
  Subject: Re: [ros-dev] rbuild auto generated resources

Marc Piulachs schrieb: 
Please can you take a few seconds to think and answer me what's the
difference between <file>source.c</file> and <localization
isoname="en-US">en-US.rc</localization>? Exacly none.
  I agree in this point. It's just a logical step to do it this way.

So instead of outsource the information (developer, translator,
language-info, etc.) from the source code to external rbuild files,
keep the data in place where it belongs to.
It's the parsers job to parse the source and extract it, and put it
together in a meaningful way (generate static output, be it xml or
html).

In my opinion is just the opposite, move the information where it really
belongs, when you talk about a developer or a translator working in a piece
of code you refer them in a particular context , in this case a whole
module, the same for mantainers or translators , they are global to the
module.

Once again, the data extracted from parsing is not TRUE metadata just
meaningless strings that you can guess or interpret : "author : jdoe" ,
"author : jhondoe" , "author : jhon doe" are 3 different persons and
<author>Jhon Doe</author> just one , I think it's obvious.
  I disagree here. IMO information about developers and translators belong to svn. They should neither go into the sources nor into rbuild files. If you want to find out about it, ask svn and it will tell you the exact name. We also don't really have maintainers for most modules, so most rbuild files would be spammed with the names of lots of developers without saying anything about who wrote a paticular piece of code.

Regards,
  Timo

------------------------------------------------------------------------------

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

[Alex Ionescu]

Yeah, and this is how Steven Edwards ended up writing most of the  
kernel according to svn blame, because he did the great work of  
removing empty lines with whitespaces.

--
Best regards,
Alex Ionescu

On 11-Nov-07, at 6:19 PM, Magnus Olsen wrote:
> authure names
> Marc Piulachs  have u heard about svn blame
> it review which person wrote a special file and which line that
> person have done a change.
> ----- Original Message -----
> From: Timo Kreuzer
> To: ReactOS Development List
> Sent: Sunday, November 11, 2007 11:56 PM
> Subject: Re: [ros-dev] rbuild auto generated resources
>
> Marc Piulachs schrieb:
> > Please can you take a few seconds to think and answer me what's the
> > difference between <file>source.c</file> and <localization
> > isoname="en-US">en-US.rc</localization>? Exacly none.
>
> I agree in this point. It's just a logical step to do it this way.
> > > So instead of outsource the information (developer, translator,
> > > language-info, etc.) from the source code to external rbuild files,
> > > keep the data in place where it belongs to.
> > > It's the parsers job to parse the source and extract it, and put it
> > > together in a meaningful way (generate static output, be it xml or
> > > html).
> >
> > In my opinion is just the opposite, move the information where it  
> > really
> > belongs, when you talk about a developer or a translator working  
> > in a piece
> > of code you refer them in a particular context , in this case a whole
> > module, the same for mantainers or translators , they are global  
> > to the
> > module.
> >
> > Once again, the data extracted from parsing is not TRUE metadata just
> > meaningless strings that you can guess or interpret : "author :  
> > jdoe" ,
> > "author : jhondoe" , "author : jhon doe" are 3 different persons and
> > <author>Jhon Doe</author> just one , I think it's obvious.
>
> I disagree here. IMO information about developers and translators  
> belong to svn. They should neither go into the sources nor into  
> rbuild files. If you want to find out about it, ask svn and it will  
> tell you the exact name. We also don't really have maintainers for  
> most modules, so most rbuild files would be spammed with the names  
> of lots of developers without saying anything about who wrote a  
> paticular piece of code.
>
> Regards,
> Timo
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Steven Edwards]

On Nov 11, 2007 6:34 PM, Alex Ionescu [e-mail] wrote:
> Yeah, and this is how Steven Edwards ended up writing most of the kernel
> according to svn blame, because he did the great work of removing empty
> lines with whitespaces.

Well someone had to rewrite it given the poor job you and David Welch did. =P
-- 
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

[Marc Piulachs]

Ohhh , really ?

_____

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Magnus Olsen
Sent: Monday, November 12, 2007 12:19 AM
To: ReactOS Development List
Subject: Re: [ros-dev] rbuild auto generated resources

authure names

Marc Piulachs  have u heard about svn blame

it review which person wrote a special file and which line that
person have done a change.

----- Original Message -----

From: Timo Kreuzer mailto:[e-mail]

To: ReactOS mailto:[e-mail]  Development List

Sent: Sunday, November 11, 2007 11:56 PM

Subject: Re: [ros-dev] rbuild auto generated resources

Marc Piulachs schrieb:

Please can you take a few seconds to think and answer me what's the
difference between <file>source.c</file> and <localization
isoname="en-US">en-US.rc</localization>? Exacly none.

I agree in this point. It's just a logical step to do it this way.

So instead of outsource the information (developer, translator,
language-info, etc.) from the source code to external rbuild files,
keep the data in place where it belongs to.
It's the parsers job to parse the source and extract it, and put it
together in a meaningful way (generate static output, be it xml or
html).

In my opinion is just the opposite, move the information where it really
belongs, when you talk about a developer or a translator working in a piece
of code you refer them in a particular context , in this case a whole
module, the same for mantainers or translators , they are global to the
module.

Once again, the data extracted from parsing is not TRUE metadata just
meaningless strings that you can guess or interpret : "author : jdoe" ,
"author : jhondoe" , "author : jhon doe" are 3 different persons and
<author>Jhon Doe</author> just one , I think it's obvious.

I disagree here. IMO information about developers and translators belong to
svn. They should neither go into the sources nor into rbuild files. If you
want to find out about it, ask svn and it will tell you the exact name. We
also don't really have maintainers for most modules, so most rbuild files
would be spammed with the names of lots of developers without saying
anything about who wrote a paticular piece of code.

Regards,
Timo

_____

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

[Marc Piulachs]

Hi Timo,

In my opinion is just the opposite, move the information where it really
belongs, when you talk about a developer or a translator working in a piece
of code you refer them in a particular context , in this case a whole
module, the same for mantainers or translators , they are global to the
module.
> I disagree here. IMO information about developers and translators belong to

svn. They should neither go into the sources nor into rbuild files. If you
> want to find out about it, ask svn and it will tell you the exact name. We

also don't really have maintainers for most modules, so most rbuild files
would >be spammed with the names of lots of developers without saying
anything about who wrote a paticular piece of code.

I understand your point of view , but let me explain a little better what
was the real intention behind developer/translator and maintainer elements ,
It was not really designed to replace svn author info nor developer names in
source files .Also not anyone sending a patch should be in the
mantainers/developers ,  The idea was to generate a "non strict" dinamic map
of who has contributed significant amounts of code to a particular module or
which developers are the current mantainers. Basically it was designed as a
internal tool for us to assist ros developers and occasional contributors in
finding the right person to contact , also can be useful to have a general
idea of a developer profile just looking at the modules he has contributed
more or less as a who is who on reactos (but dynamically created)

To summarize , it does not replace anthing just an enchancement.

Having said that this feature is not really important I thought it could be
useful but I'm not opposite to remove it if we are not going to use it.

Regards,

Marc

[Ged]

Timo Kreuzer wrote:
> Marc Piulachs schrieb:
> > Please can you take a few seconds to think and answer me what's the
> > difference between <file>source.c</file> and <localization
> > isoname="en-US">en-US.rc</localization>? Exacly none.
>
> I agree in this point. It's just a logical step to do it this way.

I don't , there is a huge difference!
source.c is a single file which is compiled as a unit.
en-US.rc is part of the top level resource file and is not built as a 
single unit, but is included as part of the top level resource file.
Hence, we only need the top level resource as part of the project, 
including seperate lanuage files leads you to think they are built as a 
seperate file, in which case it will conflict with including it in the 
top level file.

If you look at any VS project, you will not see en-EN.rc as a project 
file in the same way you won't see windef.h as part of the project.

Ged.

[Alex Ionescu]

On 11-Nov-07, at 6:27 PM, Ged wrote:
> Timo Kreuzer wrote:
> > Marc Piulachs schrieb:
> > > Please can you take a few seconds to think and answer me what's the
> > > difference between <file>source.c</file> and <localization
> > > isoname="en-US">en-US.rc</localization>? Exacly none.
> >
> > I agree in this point. It's just a logical step to do it this way.
>
> I don't , there is a huge difference!
> source.c is a single file which is compiled as a unit.
> en-US.rc is part of the top level resource file and is not built as a
> single unit, but is included as part of the top level resource file.
> Hence, we only need the top level resource as part of the project,
> including seperate lanuage files leads you to think they are built  
> as a
> seperate file, in which case it will conflict with including it in the
> top level file.
>
> If you look at any VS project, you will not see en-EN.rc as a project
> file in the same way you won't see windef.h as part of the project.

Actually you will, in a real VS project. Again, rbuild's msvc backend  
sucks because it doesn't do this, resulting in autocomplete not  
working correctly, because MSVC doesn't "know" about the header  
(whereas if the header is in the "headers" part of the project, then  
it knows about it, can search through it, etc.)

Same applies to .rc files.
> Ged.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

--
Best regards,
Alex Ionescu

[Ged]

Alex Ionescu wrote:
> Actually you will, in a real VS project. Again, rbuild's msvc backend  
> sucks because it doesn't do this, resulting in autocomplete not  
> working correctly, because MSVC doesn't "know" about the header  
> (whereas if the header is in the "headers" part of the project, then  
> it knows about it, can search through it, etc.)
>
> Same applies to .rc files.

Yes, in a project initially built by VS the standard layout is very 
different.
I'm refering to our project structure though, adding the files as 
apparaently seperate units would go against our file layout and require 
us to change all our modules, including Wine stuff.

[Marc Piulachs]

Ged, you misunderstood my rhetorical question :) , I was not asking the
literal difference between both , of course are different! I was asking it
from a conceptual point of view.

Regards
/Marc

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Ged
Sent: Monday, November 12, 2007 12:28 AM
To: ReactOS Development List
Subject: Re: [ros-dev] rbuild auto generated resources

Timo Kreuzer wrote:
> Marc Piulachs schrieb:
> > Please can you take a few seconds to think and answer me what's the
> > difference between <file>source.c</file> and <localization
> > isoname="en-US">en-US.rc</localization>? Exacly none.
>
> I agree in this point. It's just a logical step to do it this way.

I don't , there is a huge difference!
source.c is a single file which is compiled as a unit.
en-US.rc is part of the top level resource file and is not built as a 
single unit, but is included as part of the top level resource file.
Hence, we only need the top level resource as part of the project, 
including seperate lanuage files leads you to think they are built as a 
seperate file, in which case it will conflict with including it in the 
top level file.

If you look at any VS project, you will not see en-EN.rc as a project 
file in the same way you won't see windef.h as part of the project.

Ged.

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