[m-dev.] infrastructure for libmer_ssdb
Peter Wang
novalazy at gmail.com
Fri Oct 19 14:12:15 AEST 2007
On 2007-10-15, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>
> There is a list of places in scripts/c2init.in that need to be
> updated when a new library is added (there is a pointer to this list
> in the top-level Mmakefile). Unless there is a technical reason why this
> has not yet happened, could one of the developers working the ssdb
> please fix this (one of the places that hasn't been updated is c2init.in
> itself.)
The ssdb code depends on the library, and in the future may also depend
on mdbcomp and the browser. I've currently added --no-ssdb to LIB_FLAGS
so predicates in the library won't make calls to predicate in the ssdb
directory. Perhaps the same should be done for mdbcomp and browser?
Eventually I guess we'd want to be able to debug library and mdbcomp
code, which would introduce cyclic dependencies. How would we deal with
that?
Where does ssdb fit in this list? It'll help me to update the scripts,
which often orders things according to this list.
* trace library (trace/libmer_trace.a)
* browser library (browser/libmer_browser.a)
* mdbcomp library (mdbcomp/libmer_mdbcomp.a)
* standard library (library/libmer_std.a)
* runtime library (runtime/libmer_rt.a)
* Boehm collector (boehm_gc/libgc.a)
Peter
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to: mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions: mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------
More information about the developers
mailing list