[Couenne] Dependencies and library build order

[Tony Kelman]

Pietro,
(and anyone else who may have an opinion about this)

There’s been discussion here https://projects.coin-or.org/BuildTools/ticket/105 about explicitly linking dependencies into shared libraries (at least optionally), which is needed for using COIN solvers in Python/Julia, packaging for Debian, building Windows DLL’s via autotools in Cygwin/MinGW, and it can fix some occasional linking errors. For most projects this is doable with a few extra lines in automake. Couenne, on the other hand, appears to have a sort-of-circular dependency in the order it builds its libraries.

If you build with LDFLAGS=”-Wl,--no-undefined”, you can see that Couenne/src/libCouenne depends on Couenne/src/main/libBonCouenne, but the couenne AMPL executable also gets built in Couenne/src/main. The couenne executable depends on Couenne/src/readnl/libCouenneReadnl, which depends on Couenne/src/libCouenne. I can think of a few ways in which this could be rearranged in order to resolve the problem and make building Couenne with --no-undefined possible:

A) Remove Couenne/src/main/libBonCouenne, and compile its three source files into Couenne/src/libCouenne instead.

B) Move one or more of the existing libraries and/or executables into a different folder, so the dependency order of libBonCouenne, then libCouenne, then libCouenneReadnl, then couenne executable can be respected without ever having to leave and re-enter a directory (which would be rather difficult to express in terms of Makefile dependencies).

C) Leave Couenne/src/main/libBonCouenne where it is, but also compile its three source files into Couenne/src/libCouenne, possibly only when the --enable-dependency-linking option (which was recently created for this purpose) is provided to configure.

I went with approach C in my patch at the above link because it required the fewest changes, however I don’t know if it is safe to duplicate code like that in both libCouenne and libBonCouenne. Which one of these approaches do you think would be the safest, most maintainable and least disruptive option to consider?

Thanks,
Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/couenne/attachments/20131120/319e4f52/attachment.html>