[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] [Bug-gnucap] gnucap fails at start due to " ^ ? ..
From: |
Felix Salfelder |
Subject: |
Re: [Gnucap-devel] [Bug-gnucap] gnucap fails at start due to " ^ ? .. |
Date: |
Thu, 4 Aug 2016 21:20:17 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Thu, Aug 04, 2016 at 02:36:51PM -0400, al davis wrote:
> On Thu, 4 Aug 2016 20:28:38 +0200
> Felix Salfelder <address@hidden> 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