gnucap-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]