gnulib-tool-py
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnulib-tool-py] Modules and avoids: migrate to GNULibMode class


From: Bruno Haible
Subject: Re: [gnulib-tool-py] Modules and avoids: migrate to GNULibMode class
Date: Sat, 23 Jun 2012 18:12:59 +0200
User-agent: KMail/4.7.4 (Linux/3.1.10-1.9-desktop; KDE/4.7.4; x86_64; ; )

Hi Dmitriy,

> Sounds great! However, we really have to give a class proper name. I can
> suggest this way.
> 
> Old GNULibMode will be renamed to GNULibBase class to emphasize its nature:
> it will be used to create the most basic class and handles all methods
> which are necessary for every class which is created with pygnulib.
> New class which operates with modules and avoids (and possibly some other
> data; we may have to take a decision to move some other code here if we see
> it is necessary) will be called GNULibMode to emphasize that it is used as
> the advanced version of GNULibBase. So this is base class too, but more
> advanced than GNULibBase. GNULibImport and GNULibTestDir will be inheritors
> of the GNULibMode, of course.

I don't like the name GNULibBase, because it is not a base class to
GNULibInfo and GNULibError.

The semantics of GNULibMode, as it currently is, is that is provides
read-only operations on the virtual filesystem that comprises the
gnulib directory and the --local-dir directory. Well, except for --destdir
which is an option for writing files. Also the '--avoid' options are
tied to the processing a *list* of modules.

In some other mail, you have suggested to represent other modes by subclasses
of GNULibMode. With these two ideas together, here is a refined proposal:

1) class GNULibReadOnlyOperations
   This class provides operations that read from the virtual filesystem
   that comprises the gnulib directory and the --local-dir directory.
   Both at the level of a file (what func_lookup_file did) and at the
   level of modules (such as getAllModules). It implements the equivalent
   of
     func_lookup_file
     func_exists_module
     func_verify_module
     func_verify_nontests_module
     func_verify_tests_module
     func_get_description
     func_get_comment
     func_get_status
     func_get_notice
     func_get_applicability
     func_get_filelist
     func_filter_filelist
     func_get_dependencies
     func_get_autoconf_early_snippet
     func_get_autoconf_snippet
     func_get_automake_snippet_conditional
     func_get_automake_snippet_unconditional
     func_get_automake_snippet
     func_get_include_directive
     func_get_link_directive
     func_get_license_raw
     func_get_license
     func_get_maintainer
   fields: localdir, verbose, modcache

2) class GNULibModuleListOperations
   subclass of GNULibReadOnlyOperations
   This class provides operations that read from the virtual filesystem
   (still no writing of files) and take a module list as parameter.
   It implements the equivalent of
     func_get_tests_module
     func_acceptable
     func_modules_transitive_closure
     func_modules_transitive_closure_separately
   and the support for conditional dependencies:
     func_module_shellfunc_name
     func_module_shellvar_name
     func_module_conditional_name
     func_uncond_add_module
     func_conddep_add_module
     func_cond_module_p
     func_cond_module_condition
   In other words, it's the maximum you can do with a module list, without
   actually writing files to the file system.
   fields: modules, avoids, ...

3) class GNULibGenerator
   subclass of GNULibModuleListOperations
   This class contains routines for writing generated files that depend
   on a module list.
   It implements the equivalent of section
   "Emit generated .m4 files and Makefile.ams" in
   https://github.com/ghostmansd/gnulib-python/wiki/Architecture,
   except for the parts that are already in the superclass
   GNULibModuleListOperations.

4) class GNULibImport
   subclass of GNULibGenerator
   Implements the --import, --add-import, --remove-import, --update options,
   more precisely the parts that are not used by --create-testdir.

5) class GNULibTestDir
   subclass of GNULibGenerator
   Implements the --create-testdir option, excluding the parts that are
   shared with --import.

6) class GNULibMegaTestDir
   either a subclass of GNULibTestDir
   or a subclass of GNULibReadOnlyOperations that holds an instance of
   GNULibTestDir.
   Implements the --create-megatestdir option.

7...) Classes for the other options such as --copy-file.

How does that sound?

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]