Re: [Firebird-devel] Input wanted for the firebird2 tree

[David J. <dav...@ea...>]

Hi,
I'd like to think about most of this more, here is just one comment
On 2001.05.17 10:00:21 -0400 Mike Nordell wrote:
> David Jencks responded:
> >
> 
> > Mike Nordell wrote:
> > >
> > > I made the decision some time ago that the tree src/ was *only* to
> > > contain CVS files. No object files, no libraries, no nothing except
> > >  the CVS "copy".
> > > This includes removing the gbak files from this tree. Does anyone
> > > have a problem with this?
> >
> > These contain data that is used in the build? (restore into gdb,
> extract
> > data with pre-existing engine, use the data to generate something that
> is
> > compiled?)
> 
> Yes.
> 
> > If this is true, I think they should be in a clearly marked part
> > of src tree.
> 
> OK. I was thinking that we perhaps could move them into a binary-only
> tree
> of their own. I don't know if it's feasible, or even useful, though.
> 
> > I would try to make src contain everything and only that which
> > is data input to the compilation.
> 
> That's what I'm trying to do.
> 
> > > Where do you think the gbaks should be placed? Should they perhaps be
> > > placed as build/gbak/msg/msg.gbak ?
> >
> > Whereever they go, I might call them resources.  If we can turn them
> > into xml or text, the name would continue to make sense.
> 
> We can't. they are binary DB backups (produced by gbak). They are one of
> the
> sources for the chicken-and-egg problem we currently have.

I thought they were part of the chicken and egg problem, and I thought one
proposed solution was to extract the information into a non-db format, to
be used instead of needing the server running.  I freely admit I don't
understand what information is involved.  Can you point me to the
extraction/use code?

So, one possibility might be:
Have a freestanding extraction program db to say xml. This can be run not
as part of the build.  Maybe once, and the results put in cvs, later
modifications made to xml rather than db.

The existing db extraction part of the build modified to use the xml
instead of the db.

<big snip>
Thanks
david jencks