Hi!
I want to remove the "autoregister" feature from rbuild. Let me explain why I want to do this.
The "autoregister" feature in rbuild is used to automatically add dlls to the syssetup.inf file which require an ole server registration. The ole servers in these dlls will then be registered in the 2nd setup stage.
The gain of adding the ole server dlls to syssetup.inf automatically is almost non existant as a developer needs to add an 'autoregister' element to the rbuild file of the dll. For example: <autoregister infsection="OleControlDlls" type="DllInstall" /> The corresponding line in the 'OleControlsDll' section of syssetup.inf is: 11,,comctl32.dll,2
Please remember that the line above only needs to be added once.
Now, what do we loose by generating syssetup.inf automatically? Right now it is only the comments in this file as it is parsed and serialized by the inflib library.
OTOH, my future plans for syssetup.inf are severely hampered by the way rbuild handles syssetup.inf because rbuild is not able to create or modify a Unicode version of syssetup.inf. But, a Unicode version of syssetup.inf is required in order to replace the hard-coded creation of the start menu and desktop links in syssetup.dll by a configurable, localizable and Windows compatible inf-based method.
And finally since Timo suggested to replace rbuild by cmake: The autoregister feature would surely be one of the victims of this change. So why not drop this almost useless feature now?
What do you think?
Regards, Eric
Hi!
Hi!
OTOH, my future plans for syssetup.inf are severely hampered by the way rbuild handles syssetup.inf because rbuild is not able to create or modify a Unicode version of syssetup.inf. But, a Unicode version of syssetup.inf is required in order to replace the hard-coded creation of the start menu and desktop links in syssetup.dll by a configurable, localizable and Windows compatible inf-based method.
excellent!
What do you think?
IMHO the loss of autoregister feature compared to the gain is very acceptable. Please proceed with your plans.
Regards, Eric
kind regards, Johannes
I fully agree on this. This will also remove the need to rebuild the dll (and possibly other dependant modules) if we have to disable a registration for testing/debugging purposes.
As I previously said on IRC, we shouldn't expect making coffee from our build system.
Kind regards, Sylvain Petreolle
----- Message d'origine ----
De : Eric Kohl eric.kohl@t-online.de À : ReactOS Development List ros-dev@reactos.org Envoyé le : Dim 13 juin 2010, 20h 11min 49s Objet : [ros-dev] Removing the autoregister feature from rbuild
Hi!
I want to remove the "autoregister" feature from rbuild. Let me
explain why I want to do this.
The "autoregister" feature in rbuild is
used to automatically add dlls to the syssetup.inf file which require an ole server registration. The ole servers in these dlls will then be registered in the 2nd setup stage.
The gain of adding the ole server dlls to
syssetup.inf automatically is almost non existant as a developer needs to add an 'autoregister' element to the rbuild file of the dll.
For example:
<autoregister infsection="OleControlDlls" type="DllInstall" />
The corresponding line in the 'OleControlsDll' section of syssetup.inf
is:
11,,comctl32.dll,2
Please remember that the line
above only needs to be added once.
Now, what do we loose by generating
syssetup.inf automatically? Right now it is only the comments in this file as it is parsed and serialized by the inflib library.
OTOH, my future plans for
syssetup.inf are severely hampered by the way rbuild handles syssetup.inf because rbuild is not able to create or modify a Unicode version of syssetup.inf. But, a Unicode version of syssetup.inf is required in order to replace the hard-coded creation of the start menu and desktop links in syssetup.dll by a configurable, localizable and Windows compatible inf-based method.
And finally since Timo suggested to replace rbuild by cmake: The
autoregister feature would surely be one of the victims of this change.
So
why not drop this almost useless feature now?
What do you
think?
Regards, Eric
_______________________________________________ Ros-dev
mailing list
href="mailto:Ros-dev@reactos.org">Ros-dev@reactos.org
href="http://www.reactos.org/mailman/listinfo/ros-dev" target=_blank
Sylvain Petreolle wrote:
I fully agree on this. This will also remove the need to rebuild the dll (and possibly other dependant modules) if we have to disable a registration for testing/debugging purposes.
Speaking of dlls and dependencies: I think our current approach (all modules depend on the dlls it links) is retarded. A clean rebuild of ntdll leads to a massive relink orgy. I suggest to use libraries from RosBE by default. To make sure we have all exports we ever need, we should build our own import libraries with all exports for all windows versions. We could begin with an rbuild switch that tells whether to use the import lib from reactos or from RosBE. another approach would be to seperate the dll target from the import library target, so that remake ntdll will not cause the import library to be rebuild. another problem I see with the current dependencies is that you can't remove some modules from the build because other modules depend on it.
Regards, Timo
What about making the relink depend on the modification of the spec file?
Le mercredi 16 juin 2010 21:59:31, Timo Kreuzer a écrit :
Sylvain Petreolle wrote:
I fully agree on this. This will also remove the need to rebuild the dll (and possibly
other
dependant modules) if we have to disable a registration for testing/debugging purposes.
Speaking of dlls and dependencies: I think our current approach
(all
modules depend on the dlls it links) is retarded. A clean rebuild
of
ntdll leads to a massive relink orgy. I suggest to use libraries
from
RosBE by default. To make sure we have all exports we ever
need, we
should build our own import libraries with all exports for all
windows
versions. We could begin with an rbuild switch that tells
whether to use
the import lib from reactos or from RosBE. another approach
would be to
seperate the dll target from the import library target, so that
remake
ntdll will not cause the import library to be rebuild. another
problem I
see with the current dependencies is that you can't remove
some modules
from the build because other modules depend on it.
Regards, Timo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev