CcaBuildAntiPattern

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):

resulting in
CFRFS/
CFRFS/ports/
CFRFS/bin {aka util, scripts}
CFRFS/components

next

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.

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

---