proposal for common configuration elements for ITAPS services

[Jason Kraftcheck]

On 08/27/2010 12:35 AM, Miller, Mark C. wrote:
> Hi Jason,
>
> Ok, so I have a case in which I prefer NOT specifying path to i*-Defs.inc at
> configure time and would rather do it at make time. That is when I am building
> eyeMesh browser. In reality, maybe that code really isn't complex enough to
> require autoconf anyways. I mean eyeMesh really only needs to know where
> QT is, the C++ compiler and maybe VTK (but that is optional I think)
>

I've given up on building things w/out an implementation for two 
reasons.  The first is that it is way to confusing to users when things 
get their Fortran name-mangling mixed up.  It is much easier to just use 
whatever header the implementation provides.  The second is that, unless 
one is using dlopen, there are platforms where one must resolve all 
symbols to link a shared library.

> But, the way I do things now. I configure once and then make 3 times; once
> for each implmentation using 'make -I<path-to-dir-containing-defs-file>.
>
> eyeMesh is simple so maybe re-configuring and re-making (instead of just
> re-making) for each impl is ok.
>
> But, what about a substantially larger code which
> has only a few files that depend on headers from the ITAPS implementation?
> Does that mean I'll have to re-compile the WHOLE code base because I
> have to re-configure it for each implementation? I'd like to avoid that and
> re-compile and re-link ONLY the essential pieces. Do the producers of
> the code have to be sensitive enough to this problem that they get their
> dependencies correct and is that going to be difficult?

Well, using autoconf vars rather than flags means that you could do 
something like:
   make IMESH_DEFS=... IGEOM_DEFS=...

Whether or not an implementation would actually support that is a 
different question.  The build system would have to detect that the 
implementation changed and re-compile and/or re-link as required (or 
provide a special target like "make itaps-clean").

- jason