[elephant-devel] Clbuild

[Ian Eslick]

> However, the first problem may require some creativity.
>
> It seems to me the best we could hope for is to modify our build to  
> use our standard template,
> "config.sexp", if my-config.sexp doesn't exist, and blare a warning  
> that you probably should
> understand and set those defaults yourself.  If we did that, perhaps  
> on most systems (85%) it
> would build, but it will remain fragile (not least of all to new  
> revisions of BDB).
> It might build more reliably for a CL-SQL backend or a postmodern  
> backend, but of course you
> can't use those systems without knowing at least that your have to  
> have postgres and run "createdb test",
> for example.
>

My suggestions would that the process be:
- load the core elephant code without committing to loading a  
particular data store
- if my-config doesn't exist, create it with that big warning sign but  
continue
   (only BDB users depend on it, and BDB isn't being loaded as part of  
the core so they'll
    run into the errors when they try to open a specific data store)
- Make sure the dependencies for elephant-tests is done right
- Create an asdf:test-op for a basic set of elephant tests???  Perhaps  
it complains about my-config.sexp and forces you to set a store type  
to test with?

Questions:
- Is it OK with clbuild that we load :ele-bdb, :ele-clsql from within  
our open-store procedure?
- How about the hack in elephant.asd to ensure that uffi is loaded  
when some of the code in that file is evaluated as part of the c  
library build procedure?  Do we have a problem there?
- In general, have you found in clbuild that CL-SQL is a good  
prototype for a project with multiple backends like ours.

Cheers,
Ian

> Does this sound like a reasonable solution?
>
>
>
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel