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

[Youness El Andaloussi]

> Bison *must* be optional.

why *must* it be optional? arguments about "standard tools" fall flat 
because a standard win 32 system lacks a compiler anyway... There are many 
bison implementations, including win 32 or dos versions.

As was mentioned bison is one of the most  standard compiler generation 
tools... available from many places, including installed as a standard 
package in many linux distribs.

i believe in make things work first, then make them better.

my 0.02...

Youness

[Richard Campbell]

FYI:

1) It doesn't come with a standard MingW installation.
2) There are many 'hacked' 'modified' versions of bison floating around.
3)  It adds another dependency.

Youness El Andaloussi wrote:
> > Bison *must* be optional.
>
> why *must* it be optional? arguments about "standard tools" fall flat 
> because a standard win 32 system lacks a compiler anyway... There are 
> many bison implementations, including win 32 or dos versions.
>
> As was mentioned bison is one of the most  standard compiler 
> generation tools... available from many places, including installed as 
> a standard package in many linux distribs.
>
> i believe in make things work first, then make them better.
>
> my 0.02...
>
> Youness
>
> ros-general mailing list
> [e-mail]
> http://reactos.com/mailman/listinfo/ros-general

[Youness El Andaloussi]

FYI:

1) Bison is more or less bison on most versions I tested, even hacked 
versions I have seen are backward compatible...
2) once the bison grammar has been parsed and generated, it compiles 
anywhere without the need for bison, the "it adds another dependency" 
argument is not entirely valid unless you want to make changes to the 
grammar itself
3) once something that works exists, nothing the parser to be rewritten in 
c for optimisation
4) so what if it does not come with mingw... mingw does not come with 
windows either, and bison is much smaller of a download
5) Bison remains one of the most standard compiler tools.

Le 03:23 01/12/2004, vous avez écrit:
> FYI:
> It doesn't come with a standard MingW installation.
> There are many 'hacked' 'modified' versions of bison floating around.
> It adds another dependency.

[Richard Campbell]

You are missing the point.

It is yet another download.

One of opensource's biggest problems is massive dependencies between 
projects.  I really dislike this.  Trying to build one thing often 
requires that you download 20 million other things.  I have nothing 
against bison, but i do have a problem against ROS requiring yet another 
tool.  We've done quite well thus far dependency wise (we don't even 
require MSYS) and i'd like to see it stay that way.

Youness El Andaloussi wrote:
> FYI:
> Bison is more or less bison on most versions I tested, even hacked
>
> versions I have seen are backward compatible...
> 2) once the bison grammar has been parsed and generated, it compiles 
> anywhere without the need for bison, the "it adds another dependency" 
> argument is not entirely valid unless you want to make changes to the 
> grammar itself
> 3) once something that works exists, nothing the parser to be 
> rewritten in c for optimisation
> 4) so what if it does not come with mingw... mingw does not come with 
> windows either, and bison is much smaller of a download
> 5) Bison remains one of the most standard compiler tools.
>
> Le 03:23 01/12/2004, vous avez écrit:
> > FYI:
> > It doesn't come with a standard MingW installation.
> > There are many 'hacked' 'modified' versions of bison floating around.
> > It adds another dependency.
>
> ros-general mailing list
> [e-mail]
> http://reactos.com/mailman/listinfo/ros-general

[Casper Hornstrup]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Youness 
> El Andaloussi
> Sent: 1. december 2004 04:00
> To: ReactOS General List
> Subject: Re: [ros-general] RE: [ros-dev] Must Read!!!! 
> Msi.dll andBison Alert!!!!
> > Bison *must* be optional.
>
> why *must* it be optional? arguments about "standard tools" 
> fall flat because a standard win 32 system lacks a compiler 
> anyway... There are many bison implementations, including win 
> 32 or dos versions.
>
> As was mentioned bison is one of the most  standard compiler 
> generation tools... available from many places, including 
> installed as a standard package in many linux distribs.
>
> i believe in make things work first, then make them better.
>
> my 0.02...
>
> Youness

Because you would add 5 minutes or so to the time your average
new developer will need to spend in order to set up an environment.
That is 5 minutes extra *just* because he needs to generate two files
out of approx. 7900 (or 0,025%). It is even likely he will never need
to change these himself. If we have 100 new developers, they need to
spend an additional 8 hours total. For an average Danish IT consulting
company that is $1200 of lost revenue spent on virtually nothing.

If you want to see extreme versions of this problem, go see how
much time you need to spend on setting up an environment in order
to build eg. OpenOffice, Mono or GCC.

I'm not religious about not adding more tool dependencies, but
it must be justified. So if there is a tool that will give an
overall higher productivity then I might be for it. I am however
religious about not requiring non-free tools to develop ReactOS.

Casper

[KJK::Hyperion]

At 17.39 01/12/2004, you wrote:
> Because you would add 5 minutes or so to the time your average new 
> developer will need to spend in order to set up an environment. That is 5 
> minutes extra *just* because he needs to generate two files out of approx. 
> 7900 (or 0,025%).

why can't we just add the generated files to the CVS? everybody wins

[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

[Patrick Mauritz]

Am Dienstag, 30. November 2004 20:23 schrieb Thomas Weidenmueller:
> 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, ....

bison is an implementation of yacc(1), which is pretty standard - put other 
way: is there another standard tool(set, yacc usually goes with lex) for the 
job of building parsers in C?

the good news is that it tends to produce output that's portable, so unless 
that change is doing something wierd, it might be good enough to commit its 
output, too.

patrick mauritz
-- 
Das Streichen der führenden Nullen ist der 
große Vorteil der Informatik vor der Politik

[Robert Köpferl]

Patrick Mauritz wrote:
> Am Dienstag, 30. November 2004 20:23 schrieb Thomas Weidenmueller:
> > 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, ....

bison is really standard. What of the 'allowed' tools should one use to 
build parsers?   Ones fingertips together with gcc ? pfui
> the good news is that it tends to produce output that's portable, so unless 
> that change is doing something wierd, it might be good enough to commit its 
> output, too.

never - never commit output which has a source that's being worked on!
> patrick mauritz

[Richard Campbell]

Standard?  *looks in the mingw distro* I don't see it anywhere.

Robert Köpferl wrote:
> Patrick Mauritz wrote:
> > Am Dienstag, 30. November 2004 20:23 schrieb Thomas Weidenmueller:
> > > 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, ....
>
> bison is really standard. What of the 'allowed' tools should one use 
> to build parsers?   Ones fingertips together with gcc ? pfui
> > the good news is that it tends to produce output that's portable, so 
> > unless that change is doing something wierd, it might be good enough 
> > to commit its output, too.
>
> never - never commit output which has a source that's being worked on!
> > patrick mauritz
>
> ros-general mailing list
> [e-mail]
> http://reactos.com/mailman/listinfo/ros-general

[Steven Edwards]

--- Richard Campbell [e-mail] wrote:
> Standard?  *looks in the mingw distro* I don't see it anywhere.

Flex and Bison are industry standards. Here is a build that I know works because I used it on
Windows for my Wine porting. Just because the Mingw people are pointing to a old broken build is
not our problem.

http://unc.dl.sourceforge.net/sourceforge/mingw/mingwDTK-1.0.0-alpha-1.tar.g...

Thanks
Steven

__________________________________ 
Do you Yahoo!? 
All your favorites on one personal page � Try My Yahoo!
http://my.yahoo.com

[Jason Filby]

Hi

I am not against making bison a requirement (especially since it is
Free Software and easily obtainable with no license issues), but since
so many devs are against it, perhaps we should not.

I recommend a compromise where the generated file is used by the build
and included in CVS. However, the original bison file should also be
present. There should be a readme file in the vacinity explaining
things - and the generated file should include a warning that it is
generated and by what.

Then those that want to make changes to the generated file can
download Bison and do so; committing both the new source/Bison file
and the generated file. Those not wanting a complex build process can
just ignore it and never worry about unless they want to make changes
to that generated file.

I feel that this is a good compromise.. comments?

Cheers
Jason

On Wed, 1 Dec 2004 18:03:02 -0800 (PST), Steven Edwards
[e-mail] wrote:
> Flex and Bison are industry standards. Here is a build that I know works because I used it on
> Windows for my Wine porting. Just because the Mingw people are pointing to a old broken build is
> not our problem.

[James Tabor]

Hi Jason,

Jason Filby wrote:
> Hi
>
> I am not against making bison a requirement (especially since it is
> Free Software and easily obtainable with no license issues), but since
> so many devs are against it, perhaps we should not.
>
> I recommend a compromise where the generated file is used by the build
> and included in CVS. However, the original bison file should also be
> present. There should be a readme file in the vacinity explaining
> things - and the generated file should include a warning that it is
> generated and by what.
>
> Then those that want to make changes to the generated file can
> download Bison and do so; committing both the new source/Bison file
> and the generated file. Those not wanting a complex build process can
> just ignore it and never worry about unless they want to make changes
> to that generated file.
>
> I feel that this is a good compromise.. comments?
>
> Cheers
> Jason

It's all ready in the works here. So, I'm in the process of cleaning things up.
Thanks,
James

[Jakob Eriksson]

James Tabor wrote:
> Hi Jason,
> > Then those that want to make changes to the generated file can
> > download Bison and do so; committing both the new source/Bison file
> > and the generated file. Those not wanting a complex build process can
> > just ignore it and never worry about unless they want to make changes
> > to that generated file.
> >
> > I feel that this is a good compromise.. comments?
> >
> > Cheers
> > Jason
>
> It's all ready in the works here. So, I'm in the process of cleaning 
> things up.

I'm a lurker so I usually don't say much, but there is another option I 
don't
think has been voiced:

Include bison itself in ReactOS CVS and build it and install it locally 
in the
tree when building ReactOS.

regards,
Jakob

[Jason Filby]

Hi Jakob

Good idea! I think we already do this with several tools in our /tools
path. I hope Bison is not too large and builds in a decent timeframe;
otherwise it may not be a realistic option.

Thanks
Jason

On Thu, 02 Dec 2004 11:27:00 +0100, Jakob Eriksson [e-mail] wrote:
> I'm a lurker so I usually don't say much, but there is another option I
> don't
> think has been voiced:
>
> Include bison itself in ReactOS CVS and build it and install it locally
> in the
> tree when building ReactOS.
>
> regards,
> Jakob

[Jakob Eriksson]

Jason Filby skrev:
> Hi Jakob
>
> Good idea! I think we already do this with several tools in our /tools
> path. I hope Bison is not too large and builds in a decent timeframe;
> otherwise it may not be a realistic option.

This has the added benefit of immediate bitrot detection. If the grammar 
files are always
built, we will instantly see if bison needs upgrading.

regards,
Jakob Eriksson

[Casper Hornstrup]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Jakob Eriksson
> Sent: 3. december 2004 02:32
> To: Jason Filby
> Cc: ReactOS General List
> Subject: Re: [ros-general] Must Read!!!! Msi.dll and Bison Alert!!!!
>
> Jason Filby skrev:
> > Hi Jakob
> >
> > Good idea! I think we already do this with several tools in
>
> our /tools
> > path. I hope Bison is not too large and builds in a decent
>
> timeframe;
> > otherwise it may not be a realistic option.
>
> This has the added benefit of immediate bitrot detection. If 
> the grammar files are always built, we will instantly see if 
> bison needs upgrading.

Why fix it if it isn't broke?

Casper

[Jakob Eriksson]

Casper Hornstrup skrev:
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Jakob Eriksson
> > Sent: 3. december 2004 02:32
> > To: Jason Filby
> > Cc: ReactOS General List
> > Subject: Re: [ros-general] Must Read!!!! Msi.dll and Bison Alert!!!!
> >
> > Jason Filby skrev:
> > > Hi Jakob
> > >
> > > Good idea! I think we already do this with several tools in
> >
> > our /tools
> > > path. I hope Bison is not too large and builds in a decent
> >
> > timeframe;
> > > otherwise it may not be a realistic option.
> >
> > This has the added benefit of immediate bitrot detection. If 
> > the grammar files are always built, we will instantly see if 
> > bison needs upgrading.
>
> Why fix it if it isn't broke?

Uhmm... yeah, that's what I meant.

regards,
Jakob