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

[Felix Salfelder]

On Wed, Apr 24, 2013 at 11:28:36PM -0400, al davis wrote:
> More info for developers, especially Felix and Gennady ...

Hi Al. 

yes indeed, that looks interesting to me.

> This snapshot mostly does not include other new work.  I wanted 
> to get the split build version out, because this was blocking 
> other progress.  The next step is to include your recent work.  
> The fact that it is not included here does not mean I am 
> rejecting it.

never mind, i'm aware that including (at least my) parts will need some
scrubbing first.

> New work that can be distributed as plugins should be in 
> separate tarballs  initially, like the BSIM models.  Then, after 
> beating on it a while, what is mainstream and solid should be 
> folded in.

no change here, is there?

> Patches to core (lib and include directories) need to be folded 
> in.  This is now a priority, so it would help me a lot if you 
> could submit the core patches relative to this snapshot, so they 
> can be included.

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.

> Now that it actually works with split build, it's time to change 
> revision control systems.  It looks like "git" is the choice, 
> but I invite other opinions.  I waited initially because 
> rearranging the files is something that the revision control 
> systems do not handle well.

git is great. let's use the debian repo (upstream branch) as base.

> This rearrangement was planned for a long time.  Even during 
> 2008-2009, I was working on it, but several times backed it out 
> and distributed flat because of build and install issues.

shipping an autotools build system (additionally, disjoint if you like)
would amend most headaches [1].

> It will be at gnu.org, hopefully with a backup somewhere else.
> 
> I would like to set it up so experimental branches can be here 
> too, and could use some help in doing that.

with git, you wont have to worry about either backups and branches. it
doesnt matter much where it's hosted. i can help with pushing to
somewhere like gnu.org once something is ready.

> This (split build) is also the biggest block to a stable 
> release.  It could be 0.36, but the change since 0.35 is big 
> enough that it just might be ready for a "1.0", and to come out 
> of beta.

could you enlighten me (us?) about the problems with the split build? i
can't see any. maybe you can preemptively show up some pits someone
might fall in...

have fun
felix

[1] git://tool.em.cs.uni-frankfurt.de/git/gnucap_deb (build branch)