After the last Jim Tabor`s cvs commit msi.dll builds fine for me.
Is it time to put it in the main Makefile ?
Thanks, David
I think the issue is that MSI requires GNU bison to build. And so they are trying to figure out whether to: A.force developers to download GNU bison B.include GNU bison in the tree somehow as a binary file or something or C.check the files generated by GNU bison into CVS.
And also they are trying to figure out how to make sure that when someone changes the bison files or the .c files generated from them, the changes are copied upstream to WINEHQ and not lost.
On Sat, 04 Dec 2004 17:44:26 +0800 Jonathan Wilson jonwil@tpgi.com.au wrote:
I think the issue is that MSI requires GNU bison to build. And so they are trying to figure out whether to: A.force developers to download GNU bison
possible solution, probably the cleanest one, but - as you said - requires developers to download bison.
B.include GNU bison in the tree somehow as a binary file or something
NEVER do this, unless you want to keep dozens of binary files for every possible operating system in the tree... Adding the whole bison source to the CVS probably isn't a solution, too.
or C.check the files generated by GNU bison into CVS.
another possible solution, but one should also check in the grammar files used to generate the bison output. Addintionally, in this case, every developer changing the bison files has to pay attention to also run bison...
Solutions A and C already have been already discussed on this list, they both have advantages and disadvantages. I just wanted to point out that, for obvious reasons, B *is not a solution* to the problem.
Stefan Pflueger
On Sat, 4 Dec 2004, Jonathan Wilson wrote:
or C.check the files generated by GNU bison into CVS.
Isn't it entirely possible to build MSI without using Bison at all? Having worked with Lex and Yacc to write scanners and parsers woudln't it be possible to write the MSI code in standard C. I know it makes things a lot more complicated but it would remove your dependancy problems.
Thanks,
Devin Smith
Hi,
--- Jonathan Wilson jonwil@tpgi.com.au wrote:
And also they are trying to figure out how to make sure that when someone changes the bison files or the .c files generated from them, the changes are copied upstream to WINEHQ and not lost.
Casper has provided a solution that will work. Once we move to subversion and have atomic commits we can create a patch penguin that will dump all of that patches that affect wine modules in to a que that the ReactOS-Wine maintainers can then forward to wine-patches. It wont be fully automated as we don't want to spam wine-patches with ReactOS hacks but good patches can then be reviewed with little hassle and be forwarded. If it works well then I will look at extending it or creating my own CI system that is tied to Winehq cvs.
Thanks Steven
__________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250
On 05.12.2004 07:37:10 Jonathan Wilson wrote:
as we don't want to spam wine-patches with ReactOS hacks but good patches can then be reviewed
Assuming ReactOS and WINE are written correctly, there should never be anything ReactOS requires that WINE doesnt need (or vice versa)
You are assuming a perfect world. But this is not the case. Just as an example look at shell32.dll:
- Wine uses a special version of the systray code to integrate the systray icons into Linux's desktop. - Wine maintaines some old 16 bit windows-functionality, which we don't need in ReactOS. - Currently there is going on some extensibility work in Wine's shell32 code to include a browising dialog displaying the Unix file system.
Regards,
Martin
Steven Edwards skrev:
Hi,
--- Jonathan Wilson jonwil@tpgi.com.au wrote:
And also they are trying to figure out how to make sure that when someone changes the bison files or the .c files generated from them, the changes are copied upstream to WINEHQ and not lost.
Casper has provided a solution that will work. Once we move to subversion and have atomic commits we can create a patch penguin that will dump all of that patches that affect wine modules in to a que that the ReactOS-Wine maintainers can then forward to wine-patches. It wont be fully automated as we don't want to spam wine-patches with ReactOS hacks but good patches can then be reviewed with little hassle and be forwarded. If it works well then I will look at extending it or creating my own CI system that is tied to Winehq cvs.
wow... that's great.
regards Jakob
David Kredba wrote:
After the last Jim Tabor`s cvs commit msi.dll builds fine for me.
Is it time to put it in the main Makefile ?
Thanks, David
Hi, Yes, it is safe to build and you have the option to build it with bison. But the default build is w/o bison. If anyone doesn't get to it now, tonight I will do more fixups and but it back into the main makefile. Thanks, James