Ros-dev

ros-dev@reactos.org

2 participants
5791 discussions

Re: [ros-dev] rbuild problems/suggestions
by Marc Piulachs 08 Oct '07

08 Oct '07

Anyone wants to comment on this? _____ From: Marc Piulachs [mailto:marc.piulachs@codexchange.net] Sent: Saturday, October 06, 2007 10:24 PM To: 'ros-dev(a)reactos.org' 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

2 2

Re: [ros-dev] Bugzilla error when sending notifications
by carlo.bramix 08 Oct '07

08 Oct '07

Hello, I got this error too... and I made a little disaster. I got that message when writing into bug #2711. I cleaned the off-line cache, I posted my message again, I got success but the message has been posted twice, because the previous message had been accepted despite the error screen. Sorry... Carlo Bramini >I'm getting the same error since some time. > >But for me, it only occurs when hpoussin at reactos.org is >subscribed to the >bug report (by being the bug reporter or by being on the CC >list). Sending >notifications to other E-Mail addresses seems to work fine. >Also only the E-Mail notification part is affected by this >problem, the >other changes will be saved successfully. >Using Deskzilla with such bug reports also leads to the same >problem. > >Regards, > >Colin > > >> --- Original Message --- > From: ros-dev-bounces at reactos.org [mailto:ros-dev-bounces at reactos.org] On Behalf Of Marc Piulachs >> Sent: Tuesday, October 02, 2007 5:11 PM >> To: ros-dev at reactos.org >> Subject: [ros-dev] Bugzilla error when sending notifications >> >> I'm getting this error when posting/modifying a bugreport >> >> Bugzilla has suffered an internal error. Please save this page and send it to aleksey at reactos.org with details of what you were doing at the time this message appeared. >> >> URL: http://www.reactos.org/bugzilla/process_bug.cgi >> >> There was an error sending mail from 'ReactOS.Bugzilla' to 'hpoussin at reactos.org':error when closing pipe to /usr/lib/sendmail: ------------------------------------------------------ Leggi GRATIS le tue mail con il telefonino i-mode di Wind http://i-mode.wind.it/

1 0

Techwiki start
by Timo Kreuzer 07 Oct '07

07 Oct '07

I have started a techwiki inside our wiki. It can be found at http://www.reactos.org/wiki/index.php/Techwiki/main Currently only some stuff for win32k/gdi. Please add any info about nt functionality / links / tools you'd like to share there. I still think it would be a good idea to move it into it's own wiki, so our wiki doesn't get even more messed up ;-) Timo

1 0

Re: [ros-dev] [ros-diffs] [hpoussin] 29433: ntdll.dll is a native dll
by Alex Ionescu 07 Oct '07

07 Oct '07

Nope, it's not :) On 10/7/07, hpoussin(a)svn.reactos.org <hpoussin(a)svn.reactos.org> wrote: > > Author: hpoussin > Date: Sun Oct 7 16:14:02 2007 > New Revision: 29433 > > URL: http://svn.reactos.org/svn/reactos?rev=29433&view=rev > Log: > ntdll.dll is a native dll > > Modified: > trunk/reactos/dll/ntdll/ntdll.rbuild > > Modified: trunk/reactos/dll/ntdll/ntdll.rbuild > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/ntdll/ntdll.rbuild?rev… > > ============================================================================== > --- trunk/reactos/dll/ntdll/ntdll.rbuild (original) > +++ trunk/reactos/dll/ntdll/ntdll.rbuild Sun Oct 7 16:14:02 2007 > @@ -1,6 +1,6 @@ > <?xml version="1.0"?> > <!DOCTYPE module SYSTEM "../../tools/rbuild/project.dtd"> > -<module name="ntdll" type="win32dll" entrypoint="0" > baseaddress="${BASEADDRESS_NTDLL}" installbase="system32" installname=" > ntdll.dll"> > +<module name="ntdll" type="nativedll" entrypoint="0" > baseaddress="${BASEADDRESS_NTDLL}" installbase="system32" installname=" > ntdll.dll"> > <bootstrap installbase="$(CDOUTPUT)/system32" /> > <importlibrary definition="def/ntdll.def" /> > <include base="ntdll">inc</include> > > > -- Best regards, Alex Ionescu

1 0

rbuild problems/suggestions
by Marc Piulachs 06 Oct '07

06 Oct '07

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

1 0

Re: [ros-dev] [ros-diffs] [hpoussin] 29378: Add back windres, it is still used after wrc invocation
by Steven Edwards 03 Oct '07

03 Oct '07

speaking of resources, Alexandre is now allowing binary resources in winehq git as it actually handles them in a sane way as opposed to cvs. This means you guys can drop bin2res if your using it anywhere and keeping shell32 resources in sync with Wine will be less of a diff now. Thanks Steven On 10/3/07, hpoussin(a)svn.reactos.org <hpoussin(a)svn.reactos.org> wrote: > Author: hpoussin > Date: Wed Oct 3 18:17:46 2007 > New Revision: 29378 > > URL: http://svn.reactos.org/svn/reactos?rev=29378&view=rev > Log: > Add back windres, it is still used after wrc invocation > > Modified: > trunk/reactos/Makefile > > Modified: trunk/reactos/Makefile > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/Makefile?rev=29378&r1=2937… > ============================================================================== > --- trunk/reactos/Makefile (original) > +++ trunk/reactos/Makefile Wed Oct 3 18:17:46 2007 > @@ -298,6 +298,7 @@ > objcopy = $(Q)$(PREFIX_)objcopy > dlltool = $(Q)$(PREFIX_)dlltool > strip = $(Q)$(PREFIX_)strip > +windres = $(Q)$(PREFIX_)windres > > # Set utilities > ifeq ($(OSTYPE),msys) > > > -- 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

1 0

ReactOS Development Process
by Aleksey Bragin 03 Oct '07

03 Oct '07

Hello, recently, different people raised a question: How should development process evolve with time, when ReactOS has more (much more) developers willing to contribute code? There are many possibilities, however all of them assume more or less an overhead, and need additional human resources. I will outline one suggested method, and want you (developers) to "constructively criticize it", improve it, or offer a better method. Even if it involves changing current version control system, or anything - suggest the method. So, the suggestion I've already got is this: Trunk is writable only by a so-called Integrator person (maybe a few persons). Branches are writable by a big amount of developers. Typical development process is as follows: 1. A developer creates a ticket in issue-tracking system (currently Bugzilla), where he describes what's wrong and what his change fixes/ improves. 2. He creates a branch with a name BZ-XYZ (where XYZ is ticket's number), and commits his changes there. 3. An integrator, daily, goes through all BZ-... branches, does svn merge to trunk of each branch, test it, if no regression occurs, he commits changes to trunk and svn deletes the respective BZ-... branch. Some kind of integration system is definitely needed, so please avoid fast answers like "Let's stay as we do now". Better approach is needed, and I'm looking for it. If you can offer something - do so. With the best regards, Aleksey Bragin.

3 2

Re: [ros-dev] ReactOS Development Process
by Aleksey Bragin 03 Oct '07

03 Oct '07

I considered that, but it's a bad idea. Try to remember what the hell it was to merge changes into release branch ("stable"), done since 0.3.3-RC1 was released? And that was only to do a RC2, about 1-2 weeks, and complete hell to merge so it was decided that a rebranch was easier (and in fact it worked very well). WBR, Aleksey Bragin. On Oct 3, 2007, at 9:03 PM, Magnus Olsen wrote: > Hi > I think we should have something call stable trunk and devloping trunk > > The stable trunk getting all changes that are ready and stable and > it will > be > the release version of trunk. > > the devloping trunk is where everyone working in > > > But the main problem is we do not have any good tools for regress > testing > and we are missing testcase for each api. I am working at moment > writing > testcase for gdi32, I hope this will make lest gdi32 allot more > stable at > end > then I will start making testcase for win32k later maybe for user32 > then start fixing the real bugs and implement things. or working with > everthing same times. we should need a test kit for each api and > test for evertging invaild param, pointers, and real data in all case > I known it is not fun todo but that is what we need to make ReactOS > more stable and less bugs. Testcase for everthing.

1 0

Re: [ros-dev] ReactOS Development Process
by Aleksey Bragin 03 Oct '07

03 Oct '07

Herve suggests using a kind of a continuous integration system, describing it this way: * precommit hook if commit not to trunk, abort precommit hook create a REV-abc branch from trunk and do the commit here * regularly go through all REV-abc branches (increasing ABC numbers) test it if not, inform user or whatever that test failed and go to next branch try to merge to trunk if not, inform user or whatever that merge failed and go to next branch commit to trunk delete the branch go to next branch * pros: devs and users will have new version to trunk once they are tested devs and users only have to know trunk * cons: changes are not immediatly available for everyone, except in REV-abc branch On Oct 3, 2007, at 12:50 PM, Aleksey Bragin wrote: > Hello, > recently, different people raised a question: How should development > process evolve with time, when ReactOS has more (much more) > developers willing to contribute code?

5 4

Bugzilla error when sending notifications
by Marc Piulachs 02 Oct '07

02 Oct '07

I'm getting this error when posting/modifying a bugreport Bugzilla has suffered an internal error. Please save this page and send it to aleksey(a)reactos.org with details of what you were doing at the time this message appeared. URL: http://www.reactos.org/bugzilla/process_bug.cgi There was an error sending mail from 'ReactOS.Bugzilla' to 'hpoussin(a)reactos.org':error when closing pipe to /usr/lib/sendmail:

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev