Antipattern 1: duplicated nested directory hierarchies inflicted on unsuspecting users
To give an example, it's been proposed that a set of command line tools should set up a project something like so (where a project is one or more sidl-packages):
createProject CFRFS
resulting in
CFRFS/
CFRFS/ports/
CFRFS/bin {aka util, scripts}
CFRFS/components
next
cd CFRFS
addComponent cfrfs.namespace1.Comp1
addPort cfrfs.Port1
addComponent cfrfs.namespace2.Comp2
and that, before babel is even invoked, should yield
CFRFS/ports/cfrfs/
CFRFS/components/cfrfs/namespace1/Comp1/
CFRFS/components/cfrfs/namespace2/Comp2/
with the likely invocation of
babel -g from the directory where the handedited stuff lives we'll then get
CFRFS/components/cfrfs/namespace1/Comp1/cfrfs/namespace1/
CFRFS/components/cfrfs/namespace2/Comp2/cfrfs/namespace2/
and we see the that pretty soon the text-oriented developer is in a directory hell and the only way around it is to set the prompt through some shell trick to show the complete path below $HOME.
Some may say
So get rid of the -g to babel, I don't like the extra my/packageN. This then exposes that probably in both cases my/packageN should be got rid of.
Here's the sane person's alternative to the antipattern, the pattern observed in several real projects to date (CFRFS, CCAChem).
For the same command line invocations above end up with (by default):
CFRFS/ports/CFRFS.ports.sidl
CFRFS/components/Comp1/cfrfs.namespace1.Comp1.sidl
CFRFS/components/Comp2/cfrfs.namespace2.Comp2.sidl
Which contains all the same information with a lot less indirection to confuse the user, confuse make, etc.
The user is then free to choose -g in babel or not or to override the output location, e.g.
addComponent -o components/cfrfs/namespace1/Comp1 cfrfs.namespace1.Comp1
yielding for the long-path-fans:
CFRFS/components/cfrfs/namespace1/Comp1/cfrfs.namespace1.Comp1.sidl
and for the -g fans
CFRFS/components/cfrfs/namespace1/Comp1/cfrfs/namespace1/*Comp1_Impl*
-Ben