[Coin-ipopt] MUMPS 'independent' package for use with IPOPT

[John Pye]

Hi Stefan,

Stefan Vigerske wrote:
> Hi,
>   
>> I have been working on improving my RPM package for IPOPT so that it
>> could be submitted for inclusion in Linux distros such as Fedora and
>> SUSE. One major obstacle is that IPOPT provides 'configure' and 'make'
>> actions for MUMPS that AFAICT are not built into the original MUMPS tarball.
>>
>> Is there any way that a patch for the original MUMPS tarball could be
>> provided, so that one could first build MUMPS and install it, then,
>> entirely separately, unpack the IPOPT tarball, detect the installed
>> version of MUMPS, and use that to build IPOPT? This approach that I
>> describe is that which is required when submitting packages for
>> inclusion in the linux distros; it is not allowed for a package to
>> compile its own 'private' copy of a dependency as is currently done in
>> the IPOPT build process.
>>     
>
> There is the Ipopt configure option --with-mumps-dir to specify the
> location of a separately compiled MUMPS. So, if you do not have a MUMPS
> in ThirdParty but specify this flag, then Ipopts configure should use
> the MUMPS from there.
>   

The issue is how to tell IPOPT about MUMPS, but how to actually compile
MUMPS in a nice way.

My concern was that the MUMPS as distributed does *not* include
autotools 'configure' scripts etc, but the IPOPT ThirdParty build of
MUMPS *does* use autotools and is therefore perhaps a preferable build
process. So, if there was some way that someone could provide a patch
for MUMPS to allow it to be built in the IPOPT way then I could use that
approach, and be sure that it would work correctly with IPOPT on as many
platforms as possible. But the reason that this is not trivial is that
the IPOPT build process is driven from the top level, AFAICT, and it's
hard to extract just the portion of the build process that corresponds
to MUMPS.

Furthermore, my quick look at the MUMPS Makefile doesn't seem to suggest
that its build process provides a shared library, which is certainly
preferred when creating reusable RPM/Deb binary packages.

Cheers
JP
-------------- next part --------------
A non-text attachment was scrubbed...
Name: john_pye.vcf
Type: text/x-vcard
Size: 277 bytes
Desc: not available
Url : http://list.coin-or.org/pipermail/ipopt/attachments/20071122/35bcdd39/attachment.vcf