[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] gnucap development snapshot 2013-04-23

From: Felix Salfelder
Subject: Re: [Gnucap-devel] gnucap development snapshot 2013-04-23
Date: Thu, 25 Apr 2013 22:00:13 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

Hi Al.

On Thu, Apr 25, 2013 at 02:00:52PM -0400, al davis wrote:
> On Thursday 25 April 2013, Felix Salfelder wrote:
> > would you mind renaming lib to src? that would make porting
> > much easier, as the history (well half of it) wont be hosed.
> > some fixes we have talked about here are already commited to
> > gnucap-uf and could be simply cherry-picked.
> what do others think?

i cant find much about directory structure conventions but [1]:

The sources and headers for the project's main application will be
stored in yet another subdirectory, traditionally named `src'. There are
other conventional directories your developers might expect too: A `doc'
directory for project documentation; and a `test' directory for the
project self test suite. 

> calling it "lib" is consistent with other programs.

depends on whether you consider libgnucap to be part of the 'main
application'. i think i do.

> half?  more like a quarter, but even so, the real history is in 
> RCS, which doesn't carry over anyway.  It has gotten quite messy 
> over the years.  Those are all factors in my thought of wait for 
> the split, then start clean.

well yes, it would make more sense to move lib, include and main back to
src (as part of the main program). but i know, theres no point in asking
for that :/

it's all about rebasing the history of gnucap-uf which i need to do
somehow. that would be much easier without the directory breakage.

> Having it NOT called src was an important part of my migration 
> procedure ... for a while keeping new and old in parallel.

i see.

> I do think the "apps" part is up for discussion.  As it stands, 
> "apps" is all of the plugins that are loaded by default.   
> Should it be split, perhaps "devices" "commands" etc.??  Should 
> they be compiled one by one and a config file lists which to 
> add?

unfortunately "apps" leaves a bad taste nowadays, which probably was not
intended. so i'd vote for renaming (while we're at it). "lib" is a
possible name for the loadable modules directory (the terminology used
in DLOPEN(3) is "dlopen() loads the dynamic library [...]"). also
"plugins", or "modules" is fine but has more characters.

i think theres no gain in multiple plugin directories. seperating
devices from commands just complicates compiling all in one library.
splitting up source to different libraries (optionally?) wont require
seperate directories.

my 2cts


reply via email to

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