Hi All!
Jim Tabor wrote:
CVSROOT: /CVS/ReactOS Module name: reactos Repository: reactos/lib/msi/ Changes by: jimtabor@mok.osexperts.com 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
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of James Tabor Sent: 30. november 2004 19:46 To: ros-dev@reactos.com; 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: jimtabor@mok.osexperts.com 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.cpackage.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.patchLog 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
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
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 ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
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.
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 ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
-----Original Message----- From: ros-general-bounces@reactos.com [mailto:ros-general-bounces@reactos.com] 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
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
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
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
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
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 ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
--- Richard Campbell eek2121@comcast.net 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
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 steven_ed4153@yahoo.com 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.
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
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
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 jakov@vmlinux.org 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
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
-----Original Message----- From: ros-general-bounces@reactos.com [mailto:ros-general-bounces@reactos.com] 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
Casper Hornstrup skrev:
-----Original Message----- From: ros-general-bounces@reactos.com [mailto:ros-general-bounces@reactos.com] 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