Re: [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(a)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

[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 <steven_ed4153(a)yahoo.com> 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.
>
> 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(a)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
> _______________________________________________
> Ros-kernel mailing list
> Ros-kernel(a)reactos.com
> http://reactos.geldorp.nl:8080/mailman/listinfo/ros-kernel

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

[ros-kernel] about headers

[Danny Smith]

From: "Jason Filby"
> 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?

Small correction.  I don't know what "they" are aiming for.  I only know
what I am aiming for -- and that is to provide a good, affordable
compiler toolset  for the ordinary user. The SDK/DDK is a low priority
for me personally.  Right now my main priority is get pch support
working. Other mingw developers may have different priorities,
> Regards
> Jason

As already indicated

<< snip>>
> > > Speaking for myself only.
> > >
> > > Danny

[ros-kernel] about headers

[Jason Filby]

Ok thanks for clearing that up. Since our priority is SDK/DDK we'll
probably be the main submitters of such code then.

Regards
Jason

--- Danny Smith <dannysmith(a)clear.net.nz> wrote:
> From: "Jason Filby"
> > 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?
>
> Small correction.  I don't know what "they" are aiming for.  I only
> know
> what I am aiming for -- and that is to provide a good, affordable
> compiler toolset  for the ordinary user. The SDK/DDK is a low
> priority
> for me personally.  Right now my main priority is get pch support
> working. Other mingw developers may have different priorities,
> > Regards
> > Jason
>
> As already indicated
>
> << snip>>
> > > > Speaking for myself only.
> > > >
> > > > Danny
>
> _______________________________________________
> Ros-kernel mailing list
> Ros-kernel(a)reactos.com
> http://reactos.geldorp.nl:8080/mailman/listinfo/ros-kernel

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

[ros-kernel] about headers

[Steven Edwards]

Hey Danny,
--- Danny Smith <dannysmith(a)clear.net.nz> wrote:
> Small correction.  I don't know what "they" are aiming for.  I only
> know
> what I am aiming for -- and that is to provide a good, affordable
> compiler toolset  for the ordinary user. The SDK/DDK is a low
> priority
> for me personally.  Right now my main priority is get pch support
> working. Other mingw developers may have different priorities,

I understand the w32api package is a low on the radar but you and Erine
are the main points of contacts so I will direct the questions to you.

1. Is the w32api supposed to be a SDK/DDK package? 
The answer seems like a yes.

2. Do we want to try and help create a standard for open source Windows
development?

The WINE people have taken great efforts to make building Winelib
application act the same as building a application using Mingw. For me
the answer is a big yes. How about the rest of the ReactOS and Mingw
people?

3. Can we create a enviroment that all the project involved can work
together on?

I think the answer is yes but is it worth the work to everyone? Do we
want to try and support a enviroment that is the same on all platforms
and where all of the applications should run the same? Here is my wish
list all partys involved.

 - I want to be able to build ReactOS, WINE and Open Source Windows
Drivers/Apps with as little headache as possible. This means having a
common SDK/DDK.

 - I want to be sure that my app is going to run the same if it is a
Mingw compiled application, a Winelib App or a program running under
ReactOS (Running Properly under Windows is understood).

 - I want to try to create a system that makes it easy for anyone to
jump in and help any of our projects.

The relationship with the WINE/Mingw/ReactOS has been good in the past
and we want to keep it that way and make it better. I for one think
this is the best way to do this but I have been known to have been
wrong once or twice before =)

"Can't we all just get along......"

Thanks
Steven

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