Must Read!!!! Msi.dll and Bison Alert!!!!

[James Tabor]

Hi All!

Jim Tabor wrote:
> CVSROOT:	/CVS/ReactOS
> Module name:	reactos
> Repository:	reactos/lib/msi/
> Changes by:	[e-mail]	04/11/30 11:10:55
>
> Added files:
>    reactos/lib/msi/: .cvsignore Makefile Makefile.in 
>                      Makefile.ros-template action.c cond.y create.c 
>                      distinct.c handle.c insert.c msi.c msi.spec 
>                      msipriv.h msiquery.c order.c package.c query.h 
>                      record.c regsvr.c select.c sql.y string.c 
>                      suminfo.c table.c tokenize.c update.c 
>                      version.rc where.c winehq2ros.patch
>
> Log message:
>    First port of Wine projects msi.dll

With this commit, we will be using bison to build cond.y and sql.y.
Okay, for those using a Window 32 based system 8^p you will need
*bison*!

http://gnuwin32.sourceforge.net/packages/bison.htm
http://www.mingw.org

Good luck,
James

[Casper Hornstrup]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of James Tabor
> Sent: 30. november 2004 19:46
> To: [e-mail]; ReactOS General List
> Subject: [ros-dev] Must Read!!!! Msi.dll and Bison Alert!!!!
>
> Hi All!
>
> Jim Tabor wrote:
> > CVSROOT:	/CVS/ReactOS
> > Module name:	reactos
> > Repository:	reactos/lib/msi/
> > Changes by:	[e-mail]	04/11/30 11:10:55
> >
> > Added files:
> >    reactos/lib/msi/: .cvsignore Makefile Makefile.in 
> >                      Makefile.ros-template action.c cond.y
>
> create.c
> >                  distinct.c handle.c insert.c msi.c msi.spec 
> >                  msipriv.h msiquery.c order.c 
>
> package.c query.h
> >                  record.c regsvr.c select.c sql.y string.c 
> >                  suminfo.c table.c tokenize.c update.c 
> >                  version.rc where.c winehq2ros.patch
> >
> > Log message:
> >    First port of Wine projects msi.dll
>
> With this commit, we will be using bison to build cond.y and sql.y.
> Okay, for those using a Window 32 based system 8^p you will 
> need *bison*!

Bison *must* be optional.

Casper

[K McI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Casper Hornstrup wrote:
|>With this commit, we will be using bison to build cond.y and sql.y.
|>Okay, for those using a Window 32 based system 8^p you will
|>need *bison*!
|
|
| Bison *must* be optional.
|
| Casper

Any particular reason for posting the exact same thing to both lists?

~          -uniQ
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFBrMU+7mze81O92HkRAgYBAJ0SWakullWZ3kYCA9skTEdgfLvc4ACgnMyl
> tTRiKsdCYuuYgWXkBKzjKww=
> =7tHB
> -----END PGP SIGNATURE-----

[Thomas Weidenmueller]

James Tabor wrote:
> With this commit, we will be using bison to build cond.y and sql.y.
> Okay, for those using a Window 32 based system 8^p you will need
> *bison*!

I'm totally against that. The project IMO should build with the standard 
build system - i literally hate projects that need this tool, that tool, 
yet another tool, ....

Best Regards
Thomas

[Steven Edwards]

Hi,

--- Thomas Weidenmueller [e-mail] wrote:
> I'm totally against that. The project IMO should build with the
> standard 
> build system - i literally hate projects that need this tool, that
> tool, 
> yet another tool, ....

I wonder if we could import bison as a build tool in reactos/tools.
Would anyone object to that?

Thanks
Steven

__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com

[Ge van Geldorp]

> From: Steven Edwards
>
> I wonder if we could import bison as a build tool in 
> reactos/tools. Would anyone object to that?

How often do we expect the .y files to change? Wouldn't it be much easier to
put the generated files (*.tab.c and *.tab.h) in CVS? Developers actually
modifying the .y files would then need to install bison, but that seems
reasonable to me.

Ge van Geldorp.

[Magnus Olsen]

Hi
I am ageins bison. it does give me some time problem like worng version of
bison or flex in windows.
It think GVG idea are the best one to solv the bison problem.

----- Original Message ----- 
From: "Ge van Geldorp" [e-mail]
To: "'ReactOS Development List'" [e-mail]
Sent: Tuesday, November 30, 2004 8:57 PM
Subject: RE: [ros-dev] Must Read!!!! Msi.dll and Bison Alert!!!!
> > From: Steven Edwards
> >
> > I wonder if we could import bison as a build tool in
> > reactos/tools. Would anyone object to that?
>
> How often do we expect the .y files to change? Wouldn't it be much easier

to
> put the generated files (*.tab.c and *.tab.h) in CVS? Developers actually
> modifying the .y files would then need to install bison, but that seems
> reasonable to me.
>
> Ge van Geldorp.
>
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

[James Tabor]

Ge van Geldorp wrote:
> > From: Steven Edwards
> >
> > I wonder if we could import bison as a build tool in 
> > reactos/tools. Would anyone object to that?
>
> How often do we expect the .y files to change? Wouldn't it be much easier to
> put the generated files (*.tab.c and *.tab.h) in CVS? Developers actually
> modifying the .y files would then need to install bison, but that seems
> reasonable to me.
>
> Ge van Geldorp.

Well, once a year maybe depends on what wine is upto.
James

[Casper Hornstrup]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Steven Edwards
> Sent: 30. november 2004 20:41
> To: ReactOS Development List
> Subject: Re: [ros-dev] Must Read!!!! Msi.dll and Bison Alert!!!!
>
> Hi,
>
> --- Thomas Weidenmueller [e-mail] wrote:
> > I'm totally against that. The project IMO should build with the 
> > standard build system - i literally hate projects that need
>
> this tool,
> > that tool, yet another tool, ....
>
> I wonder if we could import bison as a build tool in reactos/tools.
> Would anyone object to that?
>
> Thanks
> Steven

Why not just make it optional and keep the generated files in CVS? For
most changes to ReactOS you won't need to regenerate the files.

Casper

[David Kredba]

I think that the most simple way is to include bison
to build tools.

No one must keep it in mind after that.

Regards,

David
-- 
David Kredba  <kredba at ibot.cas.cz>
GPG: ID 1024D/5B6B02DE
Fingerprint: F0B3312596BEDCF91DFB 0699E06AACD75B6B02DE

[Steven Edwards]

Hi,

--- Casper Hornstrup [e-mail] wrote:
> Why not just make it optional and keep the generated files in CVS?
> For
> most changes to ReactOS you won't need to regenerate the files.

I am fine with that. I just dont want people making changes to the
generated files and then not sending changes back to Winehq. We already
have enough trouble keeping things in sync as it is and making sure
people submit all changes back to winehq.

Thanks
Steven

__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com

[Casper Hornstrup]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Steven Edwards
> Sent: 30. november 2004 22:21
> To: ReactOS Development List
> Subject: RE: [ros-dev] Must Read!!!! Msi.dll and Bison Alert!!!!
>
> Hi,
>
> --- Casper Hornstrup [e-mail] wrote:
> > Why not just make it optional and keep the generated files in CVS?
> > For
> > most changes to ReactOS you won't need to regenerate the files.
>
> I am fine with that. I just dont want people making changes 
> to the generated files and then not sending changes back to 
> Winehq. We already have enough trouble keeping things in sync 
> as it is and making sure people submit all changes back to winehq.
>
> Thanks
> Steven

Write it in wiki. Then you can reference that if this problem occur.

Casper

[James Tabor]

Casper Hornstrup wrote:
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Steven Edwards
> > Sent: 30. november 2004 20:41
> > To: ReactOS Development List
> > Subject: Re: [ros-dev] Must Read!!!! Msi.dll and Bison Alert!!!!
> >
> > Hi,
> >
> > --- Thomas Weidenmueller [e-mail] wrote:
> > > I'm totally against that. The project IMO should build with the 
> > > standard build system - i literally hate projects that need
> >
> > this tool,
> > > that tool, yet another tool, ....
> >
> > I wonder if we could import bison as a build tool in reactos/tools.
> > Would anyone object to that?
> >
> > Thanks
> > Steven
>
> Why not just make it optional and keep the generated files in CVS? For
> most changes to ReactOS you won't need to regenerate the files.
>
> Casper

I thought it would be better to import the whole source and not have to
depend on linux builds to help the window 32 bit (soon to be ROS) make
process.

You can download and add development tools to your build system.

James

[Filip Navara]

Steven Edwards wrote:
> Hi,
>
> --- Thomas Weidenmueller [e-mail] wrote:
> > I'm totally against that. The project IMO should build with the
> > standard 
> > build system - i literally hate projects that need this tool, that
> > tool, 
> > yet another tool, ....
>
> I wonder if we could import bison as a build tool in reactos/tools.
> Would anyone object to that?

Me! Why not just commit the generated C files to CVS?

- Filip

[Alex Ionescu]

Filip Navara wrote:
> Steven Edwards wrote:
> > I wonder if we could import bison as a build tool in reactos/tools.
> > Would anyone object to that?
>
> Me! Why not just commit the generated C files to CVS?
> Filip

I agree with Filip & al

Best regards,
Alex Ionescu

[James Tabor]

Filip Navara wrote:
> Steven Edwards wrote:
> > Hi,
> >
> > --- Thomas Weidenmueller [e-mail] wrote:
> > > I'm totally against that. The project IMO should build with the
> > > standard build system - i literally hate projects that need this 
> > > tool, that
> > > tool, yet another tool, ....
> >
> > I wonder if we could import bison as a build tool in reactos/tools.
> > Would anyone object to that?
>
> Me! Why not just commit the generated C files to CVS?
> Filip

So you don't have to depend on linux to build the c files,
James

[James Tabor]

Thomas Weidenmueller wrote:
> James Tabor wrote:
> > With this commit, we will be using bison to build cond.y and sql.y.
> > Okay, for those using a Window 32 based system 8^p you will need
> > *bison*!
>
> I'm totally against that. The project IMO should build with the standard 
> build system - i literally hate projects that need this tool, that tool, 
> yet another tool, ....
>
> Best Regards
> Thomas

Well, tell that to wine. 8^)

This was a hard call to do. Knowing this team.

Wine is moving away from porting as I can see it. I've written about how
wine has cross linked third and forth level dlls (apps level). We can not
port w/o having to include some of their weird programming stuff (put nicely).
I've tried wines windows builds and w/o some of their dlls you can not use
them at all. You have to bypass ROS Second level dlls with wines. When you
try it, it doesn't work.

So, it would not hurt to use bison with their code.

Snd Point,
We started this when,,,, 1999 and now soon to be 2005. I'm to old to wait for
wine to change, so far their not trying very hard.
James

[Robert Shearman]

James Tabor wrote:
> Thomas Weidenmueller wrote:
> > James Tabor wrote:
> > > With this commit, we will be using bison to build cond.y and sql.y.
> > > Okay, for those using a Window 32 based system 8^p you will need
> > > *bison*!
> >
> > I'm totally against that. The project IMO should build with the 
> > standard build system - i literally hate projects that need this 
> > tool, that tool, yet another tool, ....
> >
> > Best Regards
> > Thomas
>
> Well, tell that to wine. 8^)
>
> This was a hard call to do. Knowing this team.
>
> Wine is moving away from porting as I can see it. I've written about how
> wine has cross linked third and forth level dlls (apps level). We can not
> port w/o having to include some of their weird programming stuff (put 
> nicely).

What exactly do you mean by this? What are third and fourth level dlls? 
What is the weird programming stuff you obviously dislike?
> I've tried wines windows builds and w/o some of their dlls you can not 
> use
> them at all. You have to bypass ROS Second level dlls with wines. When 
> you
> try it, it doesn't work.

If that is a problem with Wine DLLs then please feel free to submit 
patches for both the callers and callee. Supplying a test case that 
passes on Windows, but doesn't pass on Wine also helps.

Rob

[James Tabor]

Hi!
Robert Shearman wrote:
> What exactly do you mean by this? What are third and fourth level dlls? 
> What is the weird programming stuff you obviously dislike?

Simple app dlls, or should be simple, good example is wines advpack.dll.
Look at the wine imports compared to the real M$ advpack.dll imports you
will see. Why setupapi? advpack should be code dependent with ntdll,
kernel32, and gdi32. That was my point about that.
> > I've tried wines windows builds and w/o some of their dlls you can not 
> > use
> > them at all. You have to bypass ROS Second level dlls with wines. When 
> > you
> > try it, it doesn't work.
>
> If that is a problem with Wine DLLs then please feel free to submit 
> patches for both the callers and callee. Supplying a test case that 
> passes on Windows, but doesn't pass on Wine also helps.
>
> Rob

Yeah, we try,
James

[Ge van Geldorp]

> From: James Tabor
>
> Simple app dlls, or should be simple, good example is wines 
> advpack.dll. Look at the wine imports compared to the real M$ 
> advpack.dll imports you will see. Why setupapi? advpack 
> should be code dependent with ntdll, kernel32, and gdi32. 
> That was my point about that.

Sorry to disagree with you again, but well, I disagree....
When tracing through MS advpack.dll trying to get the IE5 installer working,
I most definitely ended up in setupapi. If you search advpack.dll (MS
version 5.0.2919.6307) for the string "setupapi" you'll get a few hits.
Seems advpack.dll LoadLibrary()s it.

Ge van Geldorp.

[KJK::Hyperion]

At 05.43 01/12/2004, you wrote:
> > What exactly do you mean by this? What are third and fourth level dlls? 
> > What is the weird programming stuff you obviously dislike?
>
> Simple app dlls, or should be simple, good example is wines advpack.dll. 
> Look at the wine imports compared to the real M$ advpack.dll imports you 
> will see. Why setupapi? advpack should be code dependent with ntdll, 
> kernel32, and gdi32. That was my point about that.

Microsoft's will load setupapi dynamically, though

[Robert Shearman]

James Tabor wrote:
> Hi!
> Robert Shearman wrote:
> > What exactly do you mean by this? What are third and fourth level 
> > dlls? What is the weird programming stuff you obviously dislike?
>
> Simple app dlls, or should be simple, good example is wines advpack.dll.
> Look at the wine imports compared to the real M$ advpack.dll imports you
> will see. Why setupapi? advpack should be code dependent with ntdll,
> kernel32, and gdi32. That was my point about that.

Is this just a philosophical point that the dependencies should be less 
than or equal to those of the Microsoft DLL, or is there some technical 
reason? Maybe we are misusing setupapi in some way. If so, please let us 
know.

Rob

[Alex Ionescu]

James Tabor wrote:
> Well, tell that to wine. 8^)
>
> This was a hard call to do. Knowing this team.
>
> Wine is moving away from porting as I can see it. I've written about how
> wine has cross linked third and forth level dlls (apps level). We can not
> port w/o having to include some of their weird programming stuff (put 
> nicely).
> I've tried wines windows builds and w/o some of their dlls you can not 
> use
> them at all. You have to bypass ROS Second level dlls with wines. When 
> you
> try it, it doesn't work.
>
> So, it would not hurt to use bison with their code.
>
> Snd Point,
> We started this when,,,, 1999 and now soon to be 2005. I'm to old to 
> wait for
> wine to change, so far their not trying very hard.
> James

All great points but I must ask, why should be bend our "rules" in order 
to be able to mingle cleanly with WINE, and why shouldn't they be the 
ones that should also try to be more flexible. From what you're saying 
(I have no personal experience to base this upon), it seems that they 
aren't trying very hard to make sure everything stays easily portable. I 
agree we need wine for the user dlls, but they also need our fixes to be 
easily implementable in their tree.

I think the best solution is for everyone to work together, and to try 
to respect our project's guidelines. If they really need to do stuff 
their own way, we really need to do stuff our own way too. Maybe some 
sort of mega conversion tool could be built or something of the sort. I 
think WINE has gotten really far, but because they are such an old 
project, they are carrying a lot of cruft that needs to cleaned out 
(just like any other project). It would be unsensical to have to import 
such cruft (I'm not referring to Bison, but those x-level DLL messes).

I don't see why the .C code would force everyone to use linux? Why would 
mingw32 not want to build it? Anyways, I restate, I'm against Bison in 
the build system (or any other similar tool) as much as I am for having 
core apps written in script languages. Considering how most of us feel 
about C++ code (imo, shouldn't be used unless it's a necessity), I think 
that starting to import Bison stuff is going to annoy a lot of people, 
judging from the reaction on the ML. I'm sure we'll find a way to 
cooperate, even it means making msi porting a bit harder.

Best regards,
Alex Ionescu

[Steven Edwards]

Hi Alex,

I understand everyones problem with bison and I agree with Filip,
Casper and GvG. Importing the generated C file in to CVS is fine as far
as I see it. The issue I worry about is people not submitting stuff
back toi Winehq and having thier code get lost in the merges. I have
some ideas about how to deal with this problem but I need to talk them
over with GvG, Eric, Filip and others that have done a lot of work on
ported Wine code.

I have tried to address some of the other questions inline.

--- Alex Ionescu [e-mail] wrote:
> All great points but I must ask, why should be bend our "rules" in
> order 
> to be able to mingle cleanly with WINE, and why shouldn't they be the
> ones that should also try to be more flexible. From what you're
> saying 
> (I have no personal experience to base this upon), it seems that they
> aren't trying very hard to make sure everything stays easily
> portable. I 
> agree we need wine for the user dlls, but they also need our fixes to
> be 
> easily implementable in their tree.

The Wine developers spent a year looking in to how to implement MSI you
would have come to the same answer they did and that was using bison to
generate the database was the best way to go. This is a tool that is
going to be used on Linux by Linux people for Linux people. I mean when
you talk about porting Wine you have to understand that Winelib runs on
Linux, Solaris, Mac OS/X. It does not get much more portable than that
for a Unix application. And yes its audited vs MS_VC from time to time.
I can build more of Wine with MS_VC than I can ReactOS.

Most of the world still laughs at the ideal of ReactOS but Wine project
(and Mingw) have been one of our closest supporters. A good number of
the Wine developers lurk on this lists and try to do things to help
both projects.

If you give a example of a real problem we have had working with them
so far then we can have that problem addressed in little to no time.
The Wine development process is a little slow but its also for all the
bad talk it gets one of the most stable and cleanest FreeSoftware
projects there is. I have never checked out Wine CVS and had the build
be broken, had a major regression that lasted more than a day or had
any problem getting a good answer as to why something could not go in
to CVS.
> I think the best solution is for everyone to work together, and to
> try 
> to respect our project's guidelines. If they really need to do stuff 
> their own way, we really need to do stuff our own way too. Maybe some
> sort of mega conversion tool could be built or something of the sort.
> I 
> think WINE has gotten really far, but because they are such an old 
> project, they are carrying a lot of cruft that needs to cleaned out 
> (just like any other project). It would be unsensical to have to
> import 
> such cruft (I'm not referring to Bison, but those x-level DLL
> messes).

This is not going to happen overnight. If you look at the revision
history of Wine you will see where Alexandre and the Wine team has
added many things to aid in our development. Supporting seperating the
Win16 and Win32 dlls in the build, adding cross-compiling support,
cleaning up the header dependancy mess in the Wine tree, removing
Wineisms/Unixisms etc....

An import/conversion tool would be nice and GvG started working on
making it a little less painful by adding support for Wine makefiles to
the build system. Importing some of the other Wine tools would make
things easy too such as WIDL and using the Wine headers but most of the
ReactOS does not want to do that.
> I don't see why the .C code would force everyone to use linux? Why
> would 
> mingw32 not want to build it? Anyways, I restate, I'm against Bison

Sure and I am not opposed to having the generated sources imported in
the CVS. We already do this for the Wine Message Compiler that we have
used in ntoskrnl and kernel32 for years.

Anyway if anyone has any ideas about how to make code sharing with Wine
more simple I am all ears. My patches to fix Wine building on MS_VC are
almost never rejected, ditto for the Win16/32 cleanups or anything else
that would make sharing code less of a pain.

Thanks
Steven

__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

[Robert Köpferl]

Sorry guys, but some of you never heared about (lets say) compiler and 
code.
Never, never import generated artifacts into a VCS.
The only thing allowed is doc and code (models). At a generated peace of 
code is not worked on (one mustn't). Instead one has to work on it's 
model (its source). This sadly implies that the matching tool (a 
compiler/transformer) must be available.
As you mentioned: People will start working on generated code (baaaad).
Also I hate projects where establishing a build env. seems like 
programming an app. But you can't ascribe everything back to Gcc as a 
minimum dominator. Gcc is not the high-level language to produce 
parsers. Try to run a make script with gcc :-/
Thus I am for adding bison to our tool list and against importing 
generated code (=not source). And think: Bison is litle more C++ affine 
than a Pascal compiler or the like.
In my sight it's not harder than providing an archive which contains 
bison beneath mingw etc.
If you want me to, I'd create that archive.

Steven Edwards wrote:
> Hi Alex,
>
> I understand everyones problem with bison and I agree with Filip,
> Casper and GvG. Importing the generated C file in to CVS is fine as far
> as I see it. The issue I worry about is people not submitting stuff
> back toi Winehq and having thier code get lost in the merges. I have
> some ideas about how to deal with this problem but I need to talk them
> over with GvG, Eric, Filip and others that have done a lot of work on
> ported Wine code.
>
> I have tried to address some of the other questions inline.
>
> --- Alex Ionescu [e-mail] wrote:
> > All great points but I must ask, why should be bend our "rules" in
> > order 
> > to be able to mingle cleanly with WINE, and why shouldn't they be the
> > ones that should also try to be more flexible. From what you're
> > saying 
> > (I have no personal experience to base this upon), it seems that they
> > aren't trying very hard to make sure everything stays easily
> > portable. I 
> > agree we need wine for the user dlls, but they also need our fixes to
> > be 
> > easily implementable in their tree.
>
> The Wine developers spent a year looking in to how to implement MSI you
> would have come to the same answer they did and that was using bison to
> generate the database was the best way to go. This is a tool that is
> going to be used on Linux by Linux people for Linux people. I mean when
> you talk about porting Wine you have to understand that Winelib runs on
> Linux, Solaris, Mac OS/X. It does not get much more portable than that
> for a Unix application. And yes its audited vs MS_VC from time to time.
> I can build more of Wine with MS_VC than I can ReactOS.
>
> Most of the world still laughs at the ideal of ReactOS but Wine project
> (and Mingw) have been one of our closest supporters. A good number of
> the Wine developers lurk on this lists and try to do things to help
> both projects.
>
> If you give a example of a real problem we have had working with them
> so far then we can have that problem addressed in little to no time.
> The Wine development process is a little slow but its also for all the
> bad talk it gets one of the most stable and cleanest FreeSoftware
> projects there is. I have never checked out Wine CVS and had the build
> be broken, had a major regression that lasted more than a day or had
> any problem getting a good answer as to why something could not go in
> to CVS.
> > I think the best solution is for everyone to work together, and to
> > try 
> > to respect our project's guidelines. If they really need to do stuff 
> > their own way, we really need to do stuff our own way too. Maybe some
> > sort of mega conversion tool could be built or something of the sort.
> > I 
> > think WINE has gotten really far, but because they are such an old 
> > project, they are carrying a lot of cruft that needs to cleaned out 
> > (just like any other project). It would be unsensical to have to
> > import 
> > such cruft (I'm not referring to Bison, but those x-level DLL
> > messes).
>
> This is not going to happen overnight. If you look at the revision
> history of Wine you will see where Alexandre and the Wine team has
> added many things to aid in our development. Supporting seperating the
> Win16 and Win32 dlls in the build, adding cross-compiling support,
> cleaning up the header dependancy mess in the Wine tree, removing
> Wineisms/Unixisms etc....
>
> An import/conversion tool would be nice and GvG started working on
> making it a little less painful by adding support for Wine makefiles to
> the build system. Importing some of the other Wine tools would make
> things easy too such as WIDL and using the Wine headers but most of the
> ReactOS does not want to do that.
> > I don't see why the .C code would force everyone to use linux? Why
> > would 
> > mingw32 not want to build it? Anyways, I restate, I'm against Bison
>
> Sure and I am not opposed to having the generated sources imported in
> the CVS. We already do this for the Wine Message Compiler that we have
> used in ntoskrnl and kernel32 for years.
>
> Anyway if anyone has any ideas about how to make code sharing with Wine
> more simple I am all ears. My patches to fix Wine building on MS_VC are
> almost never rejected, ditto for the Win16/32 cleanups or anything else
> that would make sharing code less of a pain.
>
> Thanks
> Steven
>
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Mail - Helps protect you from nasty viruses. 
> http://promotions.yahoo.com/new_mail
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

[Thomas Weidenmueller]

Robert Köpferl wrote:
> Sorry guys, but some of you never heared about (lets say) compiler and 
> code.
> Never, never import generated artifacts into a VCS.
> The only thing allowed is doc and code (models). At a generated peace 
> of code is not worked on (one mustn't). Instead one has to work on 
> it's model (its source). This sadly implies that the matching tool (a 
> compiler/transformer) must be available.
> As you mentioned: People will start working on generated code (baaaad).
> Also I hate projects where establishing a build env. seems like 
> programming an app. But you can't ascribe everything back to Gcc as a 
> minimum dominator. Gcc is not the high-level language to produce 
> parsers. Try to run a make script with gcc :-/
> Thus I am for adding bison to our tool list and against importing 
> generated code (=not source). And think: Bison is litle more C++ 
> affine than a Pascal compiler or the like.
> In my sight it's not harder than providing an archive which contains 
> bison beneath mingw etc.
> If you want me to, I'd create that archive.

Have you ever tried compiling projects like Mozilla? If not, please do. 
I'm sure that's going to change your mind...

I'm still totally against relying on 3rd party tools like bison. I 
prefer the way the ReactOS project has handled that so far.

Thomas

[Casper Hornstrup]

> In my sight it's not harder than providing an archive which 
> contains bison beneath mingw etc.
> If you want me to, I'd create that archive.

Will you also maintain it in the future?

Casper

[Robert Köpferl]

of course - as long as I stay.

By that implying that a win32/cygwin-exe of bison exists.

Casper Hornstrup wrote:
> > In my sight it's not harder than providing an archive which 
> > contains bison beneath mingw etc.
> > If you want me to, I'd create that archive.
>
> Will you also maintain it in the future?
>
> Casper
>
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

[David Kredba]

There is the mingw port of bison on mingw site.

http://www.mingw.org/download.shtml

David

Robert Köpferl wrote:
> of course - as long as I stay.
>
> By that implying that a win32/cygwin-exe of bison exists.
-- 
David Kredba  <kredba at ibot.cas.cz>
GPG: ID 1024D/5B6B02DE
Fingerprint: F0B3312596BEDCF91DFB 0699E06AACD75B6B02DE

[Robert Köpferl]

OK,... that seems fine.
So what the discussion all about?

Of course, an addiotnal tool. But when it where dunno, eiffel or a 
java-version of xerces. Than would be a problem or awful to hadle. But 
bison is (in Thomas W's words) a 2nd Party tool. OK, thus far.

So based on what I promised and what you agreed(?):
How should I maintain the archive and how put it online?
Devs: Based on that, changes and whishes go to mine. (?)

David Kredba wrote:
> There is the mingw port of bison on mingw site.
>
> http://www.mingw.org/download.shtml
>
> David
>
> Robert Köpferl wrote:
> > of course - as long as I stay.
> >
> > By that implying that a win32/cygwin-exe of bison exists.