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]" 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: References: <20160808102438 DOT 12df1886 AT jive> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Precedence: bulk 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