msi.dll

[David Kredba]

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


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

[Jonathan Wilson]

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.

[Stefan Pflüger]

On Sat, 04 Dec 2004 17:44:26 +0800
Jonathan Wilson <jonwil(a)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

[Devin Smith]

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

[Steven Edwards]

Hi,

--- Jonathan Wilson <jonwil(a)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

[Jonathan Wilson]

>   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)

[Martin Fuchs]

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

[Jakob Eriksson]

Steven Edwards skrev:

>  Hi,
>
> --- Jonathan Wilson <jonwil(a)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

[James Tabor]

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