Peter Memishian wrote: > > > > lib/lvm, where all of the libraries sharing a given Makefile > "architecture" > > > would exist below lib/ast (e.g., lib/ast/libast, lib/ast/libpp, ...), and > > > then the two Makefiles could live under lib/ast/Makefile.ast*. But I'm > > > guessing you considered that approach and had an issue with it -- so the > > > next best thing would be to have those Makefiles live directly in lib. > > > > The issue is that if OpenSolaris develops an add-on library (which AFAIK > > will happen soon for the "open"/"close"/"poll"/etc. builtins (e.g. > > compile the code and do a "builtin -f libshell.so poll ; poll --man # > > :-) ) and "procsh") and contributes this to upstream - will this library > > live under usr/src/lib/ast/, usr/src/lib/ or elsewhere ? AFAIK this is > > quickly becoming messy because there are no clear lines if libshell&co. > > get tightly integrated with some consumers within OS/Net and still > > sync'ed with upstream and/or other projects... > > If it needed to use the Makefile.ast* logic, it would live under lib/ast. > Otherwise, it wouldn't.
Uhm... IMHO that's wrong. Subdirs should be project-specific (if there is a strong need (and good justification) for such a thing (which I don't see for libshell&co. - remeber both AST and Solaris's base code (System V) share the same origin)) and not based on the underlying APIs used by the code. [snip] > > and ROOTDEMODIRBASE depends on the demo source sitting in > > "common/". > > Could it use $(SRCDIR) directly (and then one could conditionally override > $(SRCDIR) for $(ROOTDEMOFILES) if necessary?) SRCDIR is not set in this level. We're talking about usr/src/lib/lib*/Makefile, not usr/src/lib/lib*/$(TRANSMACH)/Makefile ... > > 2. Is there any recommendation what I should do when the consumer > > Makefiles of Makefile.lib do not have any demo files ? If ROOTDEMODIRS, > > ROOTDEMOFILES, ROOTDEMODIRBASE aren't defined AFAIK all hell will break > > loose - which means we need some kind of "dummy" values. > > Doesn't seem like $(ROOTDEMOFILES) being empty would be a problem. For > the other two, the convention is to use __nonexistent_directory__, as > we do with HDRDIR (and others). Ok... ... patch is done, I am waiting for a quick $ (cd usr/src ; dmake install) # to complete (and in the meantime I fetch some black tea...) ... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
