X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Injected-Via-Gmane: http://gmane.org/
To: geda-user AT delorie DOT com
From: Peter TB Brett <peter AT peter-b DOT co DOT uk>
Subject: Re: [geda-user] [RFC] Major changes to symbol/schematic libraries in geda-gaf
Date: Wed, 11 Sep 2013 08:23:36 +0100
Lines: 63
Message-ID: <877genvn2f.fsf@harrington.peter-b.co.uk>
References: <87ob83dodl DOT fsf AT harrington DOT peter-b DOT co DOT uk>
	<87sixdi6rc DOT fsf AT harrington DOT peter-b DOT co DOT uk>
	<4522f5d733a99b250d8ba670a3abae14 AT mail DOT theimps DOT com>
	<CAMvDHVDuJ7nG9kJLVSFx1NasRUVq4crVY3-uJvGrNxozqe7uhg AT mail DOT gmail DOT com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
X-Complaints-To: usenet AT ger DOT gmane DOT org
X-Gmane-NNTP-Posting-Host: cpc4-oxfd23-2-0-cust628.4-3.cable.virginmedia.com
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock: sha1:oGRL1KTZFEN106FJHqepjhq76hM=
Reply-To: geda-user AT delorie DOT com

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Vladimir Zhbanov writes:

> 2013/9/10, Peter TB Brett wrote:
> ...
>> A final point: I have been toying with the idea of allowing the file for=
mat
>> to specify resources in the form "<library_name>/<resource_name" in
>> addition to the current "<resource_name>" format.  Obviously, this breaks
>> the "abuse a library as a design cache" workflow, but on the other hand =
it
>> provides the *massive* benefit that when a user adds a library, all of t=
he
>> resources in that library are actually usable without having to figure o=
ut
>> what's happening in the other enabled libraries.  It also means that the
>> order in which a user adds libraries to a project stops being significan=
t.
>
>
> I like this idea. It allows us to eliminate masking at all and use
> multiple libraries with conflicting so far symbol names. System
> and user libraries should not conflict any more if we will use
> different names for them. If they conflict, we can just print a
> warning. To solve the issue with breaking the old workflow we
> could provide some migration instructions how to convert a local
> library into a design cache and force gschem to use symbols from
> the design cache if it will find in a schematic some entries
> having no library name.
>

The migration instructions would probably just be to convert the old
library into a project library and put it at the front of the list of
enabled libraries.  As far as I can tell, we can achieve this
automatically by executing the existing gafrc with the functions
redefined to manipulate the configuration settings.  That would
more-or-less duplicate the old workflow (especially if the cache was
turned off).

As much as I would like to just disable project-local rc files entirely,
I think there will need to be a stable series where they are still
executed but spew deprecation warnings everywhere while automatically
creating configuration files.

                       Peter

=2D-=20
Dr Peter Brett <peter AT peter-b DOT co DOT uk>

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iEUEARECAAYFAlIwGngACgkQZ7Gbq7g7vppb9gCXYvMq2WAT6ooiDD6ty0mib7ml
4gCdGf35SxuYe2tCoRo78i21VKEnoCU=
=J0h/
-----END PGP SIGNATURE-----
--=-=-=--