[Nexus-developers] NeXus makefiles

[Nick Maliszewskyj]

Yo

Mark Koennecke wrote:
> 
> High,
> 
> On Tue, 28 Oct 2003, Akeroyd, FA (Freddie)  wrote:
> 
> 
>>Hi,
>>
>>Are we not going to use autoconf and friends? 
>>if that is the way we would like to go. What is everybody else's views? 
>>
> 
>   I'am putting something together which gets us started. What I really
>   want to do is fix the proplem P^2 reported in the NeXus Java binding.
>   My proposed Makefiles are NOT incomaptible with autoconf. It makes
>   autoconf's job even easier as most of its job is done when it gets the
>   top level make_general right.

That's cool if what you mean is that your makefiles are precursors to
the makefile.in templates. We can let m4 do all the work of setting up
defines and composing which objects will be part of the ultimate
targets.

> 
>>Re libraries: I would go one step further and have "libNeXus.a" containing 
>>only the C bindings and "libNeXusF77.a" only the Fortran bindings i.e. you
>>would
>>need to specify   -lNeXusF77 -lNeXus    to link against Fortran77 and
>>similarly
>>-lNeXusF90 -lNeXus to link Fortran90. Though you have to specify multiple
>>libraries
>>for bindings other than C, it avoids the following situation: if a large
>>program required 
>>bindings in more than one language for different parts of the code, it
>>cannot link
>>against multiple libraries that each contain their own copy of napi.o 
>>
> 
>    Two points here:
>    - The Fortran API things are so small, it does not really warrant an
>      own library.
>    - I want to make things easier for the Fortran programmers, just one
>      library to link against in addition to HDF.
>    Yet another option is to link the napif.o file plus the NeXus library
>    and not to build a library.
> 
Fair enough. Even so, the core of the API is in C and I believe
that we shouldn't _require_ the presence of a FORTRAN compiler in
order to build our wrapper over HDF (this doesn't even get into
the discussion of which compiler to use and the name mangling
conventions used by it). With the core -lNeXus an application
developer can still get a lot of mileage without having to import
extra baggage for languages s/he's not using.

Nick

-- 
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
o Dr. Nicholas C. Maliszewskyj
o Center for Neutron Research
o National Institute of Standards & Technology
o 100 Bureau Drive, Stop 8562
o Gaithersburg MD 20899-8562
o nickm at nist.gov
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo