On Thu, Aug 04, 2016 at 02:36:51PM -0400, al davis wrote: > On Thu, 4 Aug 2016 20:28:38 +0200 > Felix Salfelder <[email protected]> wrote: > > > sure. what i mean is: let's lift this to user-level... > > > > > Perhaps. It needs to be done plain first. > > > > there are too many ways. which one? > > > > You are mixing the user-level with the underlying implementation. > > My answer to your question: The underlying implementation must not > prevent any of those choices,
not so fast. :D if $ $EDITOR my_gnucap_today $ make what=my_gnucap_today is supposed to work, then the toplevel will have to know about the directory contents. possible, but does not make much sense to me. also: there's only one way to keep the source files. either all in /apps or split up in /opt. if all are in /apps it is hard to select groups. if they are split up, it will be harder to link them into one default-plugins module (is that really needed?) so we should make choices that align with what a user may need. e.g. do we want to link multiple directories contents into the default plugins module, just because it is (technically/manually) possible? e.g. an underlying implementation for mere directory selection would be easy. but then how to cross-directory link the objects? i don't think there should be just one module loaded at startup... cheers felix _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
