[ros-kernel] about headers

[Steven Edwards]

This is really the heart of the issue. Can we work out a system that
will work for all projects involved? What I am about to bring up is not
the same issues that Danny has with GCCisms but it has made me think
about our build system again.

WINE and Mingw both make use of some of the aspects of the GNU
toolchain that ReactOS currently does not. I think I have a more simple
solution to our problem but most of the ReactOS will not like it.
Currenly the ReactOS project has a bad habit of importing libraries
that we need such as zlib and freetype in to our funky build system.
Then on top of that you heep on the problems of trying to support the
w32api and WINE and you get the current cluster-fu*k we have now.

1. Create vendor branches for w32api, WINE and other projects that
ReactOS needs. 
   - Now the question becomes how do we structure this? If we use the
w32api with the SDK/DDK then we can import it in to the WINE source
tree just as we have done with freetype and zlib. 

2. Can we import a vendor branch in to CVS under a existing repostory?
   - If the answer is yes then we do we need to import the whole WINE
sourcetree only selected DLL and Programs.

3a. If we can do all of this then do we switch to a GNU configure
system so we can configure all of the modules at compile time and dump
our funky build system?
   - I am thinking a layout like this:
/CVSROOT
      /reactos
           configure
           /contrib
                /w32api/configure
                /freetype/configure
                /OpenSSL/configure
                /zlib/configure
                /WINE/configure
                     /dlls
                     /programs
                     /libs

3b. Or do we leave CVS like it is now? and maybe move the external libs

to there own modules where we can Vendor branch them?

 - Moving to a GNU configure system would still make it easy on us. The
only thing is we would need to create a set of import scripts for
branching/merging and move the external libs to there own module

CVSROOT/
     /reactos
     /rosapps
     /WINE
     /support
          /w32api
          /freetype
          /zlib
          /openssl

Ok I am sorry I have taken the discussion beyond headers but we have to
find a solution that will work.

Is w32api that solution? 
Does out current build system do everything we need to be able to
scale?
How does KDE or GNOME handle this?

Thanks
Steven

--- Danny Smith <dannysmith at clear.net.nz> wrote:
> As far as the mingw runtime headers are concerned, you will have a
> hard
> time convincing me to remove all the ISO C99 extras.  You will also
> have
> a hard time convincing me that removal of all the POSIX-isms is a
> good
> thing, since they really assist building of things like binutils,
> gcc,
> libiconv, gettext, make, etc.
> 
> As someone who has had input into the maintenace of gcc compiler
> suppor
> for mingw,
> the hardest things to maintain are the MS-extensions (dllimport being
> the worst because of the ambiguity of the syntax).   Adherence to the
> MS
> "gold standard" has meant that mingw is forced to use sjlj exceptions
> rather than DWARF2.
> 
> Personally, I would prefer that mingw gcc/binutils move closer to
> theFSF
> mainstream
> rather than drifting from it.  Likewise, I would prefer that mingw
> runtime moves in dirction towards ISO C, C++ conformance (eg, make
> the C
> headers namespace aware when in C++)  rather than towards MS
> conformance.
> 
> Speaking for myself only.
> 
> Danny


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com