Distinguishing between lepton and geda-gaf

[peter-b]

lepton currently installs and uses a lot of documentation, programs and other files that clash with those installed and used by geda-gaf.

We want to be backward compatible with geda-gaf <= 1.9.2, but also want users to be able to install a newer geda-gaf alongside lepton. Also, spending a lot of time on renaming things is busy-work that does not really bring much benefit to users.

We should consider gradually migrating towards naming things based on lepton in stages. The current plan:

• Change the tarball name in configure.ac, so we can start making releases (Rename libgeda to liblepton. #47)
• Load config data from gEDA config files and save back to Lepton config files (The issue is no longer valid since the last release 1.9.10 don't even use geda.conf files and transition utility lepton-upcfg is available.)
• Add a --enable-compat-symlinks flag to configure. This will enable installing a symlink named gaf for lepton-cli, etc. It will default to yes
• Start renaming tools (etc.) with lepton
• Eventually change the default to --enable-compat-symlinks=no
• Update documentation (especially README)

Unresolved issues:

• How will we deal with installed resources, e.g. symbol libraries? (We won't do anything special until some new very different strategy is elaborated, just keep things as is, backwards compatible. It doesn't break anything.)
• How will we deal with user & system Scheme init files, e.g. $XDG_CONFIG_HOME/gEDA/gafrc?

Other related tasks:

• Rename the Coverity Scan project (Rename Coverity Scan project #43)

[vzh]

@peter-b I propose to read Scheme rc files as is in their current
paths. There is nothing to do with resource libraries until we'll
implement them other way and add settings for them to new config.

We could add some defines like this:

/*! Filename for old gEDA system configuration files /
#define OLD_SYSTEM_CONFIG_NAME "geda-system.conf"
/! Filename for gEDA user configuration files /
#define OLD_USER_CONFIG_NAME "geda-user.conf"
/! Filename for gEDA local configuration files /
#define OLD_LOCAL_CONFIG_NAME "geda.conf"
/! Filename for gEDA system configuration files /
#define SYSTEM_CONFIG_NAME "lepton-system.conf"
/! Filename for gEDA user configuration files /
#define USER_CONFIG_NAME "lepton-user.conf"
/! Filename for gEDA local configuration files */
#define LOCAL_CONFIG_NAME "lepton.conf"

and then:

• for project files just to search lepton.conf in the same paths it is searched now; if it is not found in a directory we search, look up for its geda.conf sibling in the same place; if geda-conf has been found first, immediately create analogous lepton.conf in the same directory
• for user and system files first look for appropriate lepton conf file in all its user/system conf dirs, and only then search for appropriate geda conf file. If geda conf file has been found, immediately create lepton-*.conf in the first 'canonical' place

[peter-b]

@vzh Do you have any opinion on symbol naming? In gschem, for example, we carry on with gschem_do_something(), typedef struct _GschemType GschemType, GSCHEM_MACRO_NAME, etc?

[vzh]

@peter-b Generally, I believe we should start another issue/discussion here to address the symbol naming problem. I cannot suggest now anything better than the symbol name should reflect its functionality, and contain author name for non-stock (non-shipped with the repo) symbols, and a modification number (for various sizes etc.) like before. Probably we could also include a version info into this list.

[peter-b]

Ah, sorry, by "symbol naming" I meant the naming of the exported functions and variables in libgeda, rather than the naming of schematic symbols. I'm sorry for being unclear!

[peter-b]

@vzh

• for project files just to search lepton.conf in the same paths it is searched now; if it is not found in a directory we search, look up for its geda.conf sibling in the same place; if geda-conf has been found first, immediately create analogous lepton.conf in the same directory
• for user and system files first look for appropriate lepton conf file in all its user/system conf dirs, and only then search for appropriate geda conf file. If geda conf file has been found, immediately create lepton-*.conf in the first 'canonical' place

For system config files, we will (hopefully) not have write access, and usually the tools shouldn't write to it, I guess (they should write to the user config file). For the user/system config files, I suggest setting things up so that when you load it the first time, it loads from the gEDA file, but whenever you save it it saves to the Lepton file. And the same for project files. I think it makes sense to avoid unnecessary writes to disk.

[gareth8118]

@peter-b I know I can do it but I didn't want to jump in and edit your issue unannounced - can you add a TODO item line for documentation changes? Even getting the README updated would be a big step in the renaming/rebranding exercise since it appears on the front page of the github http view of the project.

[gareth8118]

In the spirit of incremental changes being better than no changes, I've made an initial attempt at leptonising the README.md here: https://github.com/gareth8118/lepton-eda/tree/lepton-renaming-docs - not ready for a pull yet but worth reading over.

(do we have a convention for the capitalization of 'lepton'/'Lepton'?)

[peter-b]

Personally, I think that in prose it's easier to read "Lepton EDA" (or "Lepton" on 2nd & subsequent appearances).

[vzh]

@gareth8118 Agreed with Peter. One more note. When we name the program, use lepton-something, just its name. When we name the project itself, use Lepton EDA or Lepton.

[gareth8118]

Fixed up capitalisation in my branch referenced above.

[vzh]

@gareth8118 I'd suggest you to squash your changes and make a PR. We could then review its parts and add comments and thoughts of what should be changed and how. I'd prefer changes on this topic faster migrate into the repo.

Thank you for the work!

[gareth8118]

@vzh #93 opened

[vzh]

All utils seem to have been renamed.

[vzh]

Just updated the issue with my view on what we should do with component libraries. Since we're maintaining backward compatibility with geda-gaf and nothing in new Lepton code breaks users' projects, I don't see any problem with this. I believe we've did anything right to ensure our users can use both projects (lepton and geda-gaf) without interference. Please file a new bug report if something is still in your way and bothers you. Thanks in advance.