What about rewriting a _dxfImportBin_FP function just for DXL that
would not be dependent on all the other code in libdx. I think it
might be possible without too much trouble but I haven't dug really
deep into it. This is the function that is causing the hub-bub. It
seems that it would make sense that since DXL gives one a way to talk
with the executive that it should be fairly independent of the dx
internals.
Greg and Randall, let me know what you think. If you think it is a
good idea I will look at trying to implement it tomorrow.
By the way, I did do some of the updating of configure stuff (made a
configure.ac and ran autoupdate on it--then fixed a few minor
problems). I'm not sure how things should be committed to cvs. Should
I wait until I have some significant libtool stuff done or start
adding it bit by bit?
David
I see what you mean - it looks like its not possible to have one shared lib
dependent on another. Thats news to me, and sucks.
I agree that using shared libraries in OpenDX is a very good thing. There
have been those that have argued strongly in that direction for years, and
I'm glad things are moving in that direction.
Even so, I'm not comfortable throwing away functionality. So I wonder if
we ought to consider leaving libDXL a static library and requiring that it
link in the libDXlite shared lib. That would minimize the static portion -
thereby minimizing the exposure to the app builder thats inherant in static
libs, since we minimze the code in the static lib.
Greg
--
.............................................................................
David L. Thompson Visualization and Imagery Solutions, Inc.
mailto:[EMAIL PROTECTED] 5515 Skyway Drive, Missoula, MT 59804
Phone : (406)257-8530
