Skip to Content.
Sympa Menu

devel - Re: [sympa-developpers] Layout of sources

Subject: Developers of Sympa

List archive

Chronological Thread  
  • From: David Verdin <address@concealed>
  • To: address@concealed
  • Subject: Re: [sympa-developpers] Layout of sources
  • Date: Wed, 06 Nov 2013 16:45:05 +0100

Hi,

Le 04/11/13 17:21, Guillaume Rousse a écrit :
address@concealed">Hello.

Le 03/11/2013 03:50, IKEDA Soji a écrit :
Hi,

Guillaume's new directory layout seems to have a bit more room for
improvement.  For example subdirectories under src/ may be moved to
top level.
Are you talking about the trunk or the 6.2 branch?
address@concealed">

Also expecting registration to CPAN, I drafted a modified layout.
The desirability of such registration has never been discussed sofar. Altough I don't have any actual objection, I don't see much interest:
- sympa does not belong to the primary target of CPAN (it is an application, not a reusable perl library)
- sympa doesn't use ExtUtils::MakeMaker or Module::Build build system, meaning cpan clients won't be able to install it

And even if desirable, there is no constraint on internal archive structure.
To sum up: we need to have a correct modularization and get rid of circular references.
If this leads to porting some modules to CPAN, it is potentially interesting. But this is not our current priority.
address@concealed">
--------------------------------  ------------------------
Current layout                    Proposed
--------------------------------  ------------------------
doc/                              doc/
ext/                              ext/ --- Be separate modules in the future.
mail_tt2/                         default/mail_tt2/
po-wwsympa/                       po-wwsympa/
po/                               po/
src/bin/sympa.generic             sympa.generic
src/bin/sympa.in                  sympa.in
src/bin/            [OTHERS]      bin/  or  script/ [std]
src/cgi/mime.types                default/mime.types
src/cgi/            [OTHERS]      libexec/
src/etc/                          default/
src/lib/                          lib/ [std]
src/sbin/                         sbin/  or bin/ [std]
src/soap/sympa.wsdl               default/sympa.wsdl
src/soap/sympa_soap_client.pl.in  bin/  or /srcipt/ [std]
src/soap/sampleClient.php         ? --- May be moved to contrib.
src/soap/           [OTHERS]      libexec/
src/www/                          www/
t/                                t/ [std]
web_tt2/                          default/web_tt2/
--------------------------------  ------------------------

Note: "[std]" indicates (approximately) standard source layout with
ExtUtils::MakeMaker.

Resulting layout will become:

--------------------------------
bin/  or  script/ [std]
doc/
ext/
default/
lib/ [std]
libexec/
po-wwsympa/
po/
sbin/  or  bin/ [std]
t/ [std]
www/
--------------------------------
What did you think about what Guillaume had done in the sympa-cleanup branch? It looked good: every perl code in the src/Sympa directory, then more or less the same organization as the one you proposed?
address@concealed">I fail to see much advantage here in flattening the archive so much. And I even see a disadvantage, as it make usage of command-line tools as 'grep' of 'find' more difficult: you have to either specify multiple
directory targets, or filter out more noise in the output, whereas having all source code files self-contained in a single directory is much more practical.

I'd rather go the opposite way, and also try to make template and translation files isolated in their own respective hierarchies:
├── po
│   ├── mail
│   └── www
└── templates
    ├── mail
    └── www
You're wrong here for the po organization: The catalogues separation is not based on web / mail, but on user interface (po) / user online help (po-wwsympa).
And yes: po-wwsympa is very badly named. ps-help would be a better name.
By "user interface", we mean anything displayed to the final user which is not help : mails, command line and web.
The reason for this separation is: it's easier for translators to translate the user interface first, and then the user help.
address@concealed">This would first unclutter the top-level directory, make the content of those directory more self-explanatory, and enforce consistent naming for related content.
Agreed.
address@concealed">
I'm also interested, in redistributing executables in a more logical manner between the two current 'bin' and 'sbin' directories. Or to rename them differently, if their purpose was just to distinguish between core components, and auxiliary tools.
OK.
address@concealed">
The whole notion of 'standard layout' is biased here. Just because Sympa is written in Perl doesn't mean than every common practice in the Perl world automatically applies. Especially practices related to the distribution of general-purpose perl libraries.

--
A bug in Sympa? Quick! To the bug tracker!

 
David Verdin
Études et projets applicatifs
 

Tél : +33 2 23 23 69 71
Fax : +33 2 23 23 71 21
 

www.renater.fr
RENATER
263 Avenue du Gal Leclerc
35042 Rennes Cedex



PNG image

Attachment: smime.p7s
Description: Signature cryptographique S/MIME




Archive powered by MHonArc 2.6.19+.

Top of Page