delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/08/08/05:29:19

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Mon, 8 Aug 2016 11:38:05 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: "Lev (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] [pcb-rnd] release 1.1.0
In-Reply-To: <20160808102438.12df1886@jive>
Message-ID: <alpine.DEB.2.00.1608081118350.7286@igor2priv>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1608060637530 DOT 7286 AT igor2priv> <20160808102438 DOT 12df1886 AT jive>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com


On Mon, 8 Aug 2016, Lev (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:

> On Sat, 6 Aug 2016 06:44:15 +0200 (CEST)
> gedau AT igor2 DOT repo DOT hu wrote:
>
>> The file format is moved into a plugin called io_pcb; alternative
>> native file format plugins are possible now.
>
> Good news. So I can proceed with my SQLite file format io.

If you have the time and want to work on this, the best way would be a 
core plugin in pcb-rnd. If that's the case, please contact me in private 
to get commit access.

Of course you can write an external plugin kept in an external 
repository, but that might be harder to keep up to date long term, 
especially that at this phase of the project we are rather brave in 
pcb-rnd to clean up or change internals and APIs.

> Just one thing: I'd move the code configuration system to cmake. Then it is
> easier to put the code into CI system. And users are more familiar with it
> too.

Sorry, I wouldn't; I am 100% statisfied with scconfig and currently it's 
only me who is hacking any code that needs configuration support.

Some background...

The past 1 year has proven this well: theoretical user gain vs. actual 
development time investment does not pay off. So I won't jump on 
something fancy that costs a lot just because in theory it may 
bring users. Thus scconfig stays as primary configuration system.

That said, it is possible to introduce a secondary, parallel configuration 
system. This has an extra cost, as we then need to maintain two systems. I 
am open to this, but only if it's already proven that it pays of.

In other words: first join the development, invest a lot of your time on 
the development with the current system so we see that you do have the 
time and you are willing to spend your time, so we see you are going to 
care about cmake long term even when changes happen outside of the code 
zone you are interested in. Then you can add your alternative build 
system, be it cmake, autotools, imake, qmake or whatever. And no, this 
still doesn't change the primary build system state of scconfig as long as 
I am investing a lot of time in the project too.

The policy here is to add alternatives instead of pursuing the One True 
Solution, but also that "add big infra that is labour-intensive just to 
keep alive only when we are sure there's someone to keep it alive".

(An io_ plugin and core plugins in general are different story: if someone 
provides an initial implementation with a reasonable set of test cases, 
it's easy to keep it alive and forward port to code changes in core even 
if the original author later looses interest in maintaining it.)

Regards,

Igor2

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019