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@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
