[ros-dev] Very bad Idea.

[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 <ionucu(a)videotron.ca> 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
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>