On Aug 3, 2016, at 12:19 PM, Ouabache = Designworks (z3qmtr45 AT gmail DOT com)= [via geda-user AT delorie DOT com] = <geda-user AT delorie DOT com>= wrote:

On Wed, Aug 3, 2016 at 8:05 AM, John Doty <jpd AT noqsi DOT com> wrote:

On Aug 3, 2016, at 3:50 AM, Svenn Are Bjerkem (svenn DOT bjerkem AT googlemail DOT com<= /a>) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> = wrote:

> On 2 August 2016 at 23:02, John Doty <jpd AT noqsi DOT com> wrote:
>> The way I do it is to have a project symbol directory. I copy = the necessary
>> symbols from libraries into there. It=92s safer to keep = specialized symbols
>> bundled with the project anyway. Libraries get revised.
>
> As an example, a "reuse" project. New design using two legacy = modules
> which are space-proven but have never been used in the same = project
> before. The modules are created by two separate designers, both = who
> are not you.
>
> mydesign/sym/lib_eth/decoder-1.sym
> mydesign/sym/lib_uart/decoder-1.sym
>
> How to solve without renaming?

Why not rename? If you constrain the solution unnecessarily, you = just wind up with complexity.

I do import subcircuits from previous projects occasionally, and I run = into this, rarely. I don=92t see any reason that one couldn=92t write a = utility to manage this, but it=92s not worth the effort to me. These = rare cases are easily managed manually.

In any case, this is most definitely not the responsibility of the = schematic editor in a well-factored EDA toolkit.

This is the difference between a small data = environment like PCB entry and big data like a half billion gate asic. = What you see as a
rare event is now = a frequent and almost expected = occurrence.

Then make a = specialized tool to do the design merge. gEDA is well-suited for = this.

Doing anything manually is = a huge risk in any asic design. You automate everything or else you will = be buried under a tsunami of = code.

Anything? No inputs = from the designer are allowed? But I agree that complex things should be = automated.

What happens if you bring in code that needs a fix = that you simply change it yourself? Five years later a new team is = formed to design the follow on product to your current design. They will = start with your chip design and then add ,delete or modify code for the = new product. They will download the latest versions of all your modules = from their sources.

Somebody on the new team will need to go in and = exactly duplicate the work that you did on that = module.

Did you leave enough
documentation that they know what needs to be = done? As your designs grow you have to formalize and document everything = to a much greater extent than you do = now.

That=92s why a toolkit = (like gEDA) that is friendly to software-style configuration management = and automated builds and testing is a good thing. In my big gEDA = projects, a simple =93make=94 builds all of the data products. =93make = check=94 does whatever checks I can automate. If either of these is = broken on a clean clone of the source, the project is broken. A Makefile = is better than some complicated manual procedure, no matter how well = documented. For analog/mixed signal it=92s trickier: while I do checks, = simulators are not perfectly predictable unless you like keeping = obsolete binaries around to run on obsolete = hardware.