Re: [ros-kernel] about headers

[Jason Filby]

Hi Steven

We've (ReactOS) already gone beyond the header issue with the
decision to do a vendor branch of WINE. With regards to doing the
same for ZLib and FreeType: well spotted! We should definitely do the
same there.

As I understand it, with a vendor import of WINE it doesn't matter to
us (ReactOS) whether the WINE and MingW headers are duplicated or not
- thats something for WINE/MingW to decide on. All we (ReactOS) have
to worry about is getting our public header declarations out of our
tree and hope to work well with MingW as far as patches are
concerned.

The only thing that worries me is Danny saying that they're not
aiming for the Windows SDK/DDK! If this is true then we may have to
keep our own headers, public or otherwise?

Regards
Jason

--- Steven Edwards  wrote:
> 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.
> - 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.
> - 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  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
> _______________________________________________
> Ros-kernel mailing list
> [e-mail]
> http://reactos.geldorp.nl:8080/mailman/listinfo/ros-kernel

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