Re: [ros-dev] rbuild auto generated resources

[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" &lt;gedmurphy(a)gmail.com&gt;
>  To: "ReactOS Development List" &lt;ros-dev(a)reactos.org&gt;
>  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
> > >  Ros-dev(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev 
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev