Mail Archives: geda-user/2016/08/08/05:29:19
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 -