Re: [Vxl-maintainers] Contrib/brl INCLUDE_DIRECTORIES

[Wheeler, F. W (G. Research) <wh...@cr...>]

I think Amitha's solution #1 makes the most sense for these reasons:
Users of BRL can then use INCLUDE_DIRECTORIES( ${BRL_INCLUDE_DIR} ) and
be blissfully ignorant of the "internal" directory organization of the
code.  Very little change will be required, just brl/CMakeLists.txt I
think.  #includes will normally have 1 directory layer, and 2 when
"algo" is involved, which I agree is nice.

Even if Amitha's solution #2 is superior, the massive file moves would
be daunting.

Fred

-----Original Message-----
From: Amitha Perera [mailto:ami...@us...]=20
Sent: Sunday, November 11, 2007 9:28 AM
To: Joseph Mundy
Cc: Wheeler, Frederick W (GE, Research);
vxl...@li...; Krahnstoever, Nils (GE, Research)
Subject: Re: [Vxl-maintainers] Contrib/brl INCLUDE_DIRECTORIES

I want both. :-)

A one-level include directory is good, because it is easier to type.=20
However, having to remember where in the (deep) hierarchy to look for
that one level is not good.  I see two options:

1.  Change BRL_INCLUDE_DIR to be "brl/bbas;brl/bseg;brl/abc".  Then,
users of BRL stuff just need INCLUDE_DIRECTORIES( ${BRL_INCLUDE_DIR} ).=20
  The advantage here is that the solution involves very little code
change.

2.  Collapse the brl tree to a list, bringing everything to the brl
level.  This means a lot of code moves, but it has two advantages:=20
library name conflicts are easy to detect, and it is easy for non-brl
folks to track down brl code.  (I often find it difficult to trace down
what's going on in brl because I'm not sure which library is where.)

Amitha.