[Ipopt] Ipopt config and FORTRAN_INTEGER_TYPE

David Wilkinson xyz-coin at effisols.com
Sun May 21 07:29:18 EDT 2017


Thanks, Stefan. When do you think the next release will be?

Sorry I did not respond before, but I had some questions about the usage of the 
symbols IPOPT_BUILD, COINUTILS_BUILD, BONMIN_BUILD, etc. These symbols are 
introduced into the COIN-OR projects via configuration headers IpoptConfig.h, 
CoinUtilsConfig.h, BonminConfig.h, etc. If the appropriate one of these headers 
were included only at the top of every .cpp file of each COIN-OR project, then 
in any translation unit only one of these header files would be active, and 
there would be no ambiguity. However in some cases, these configuration headers 
are included in .hpp headers, so more than one of the configuration headers can 
be in effect (if the .hpp headers are used in multiple projects).

[My usual rule is that every header should contain all the other headers it 
needs to compile against an empty .cpp file, but I would relax this if there was 
a convention that one of these configuration headers be always included at the 
top of each .cpp file. The rule would then be that every header should include 
what it needs to compile against a .cpp file containing only one (but any one) 
of the configuration headers. This is analogous to the situation with the 
"stdafx.h" precompiled header file in Visual C++]

So my initial question is: Would it be possible to refactor the COIN-OR code so 
that the configuration headers were only included as the first line in a .cpp 
file, and not in any .hpp header files?

My real question has to do with the nature of our Bonmin project (so perhaps is 
really a Bonmin question). For some reason, the Visual C_++ Bonmin solution that 
we adapted contains only three library projects: libCoinUtils, libIpopt and 
libBonmin. The libBonmin project compiles both Bonmin-specific code and 
everything it needs from other projects (e.g. Cbc, Cgl).

So in this mega-Bonmin project, which of the symbols BONMIN_BUILD, CLP_BUILD, 
CLP_BUILD, CBC_BUILD, OSI_BUILD and CGL_BUILD should I be defining? Right now I 
am defining all of them, and everything seems to be OK, but it would be more 
clearly correct if the configuration headers were included only in .cpp files.

Sorry for long post.

David Wilkinson

========================

Stefan Vigerske wrote:
> Hi,
>
> yes, seems correct.
> I've added that to trunk and it should make it to the next release.
>
> Thanks,
> Stefan
>
> On 05/11/2017 04:21 PM, David Wilkinson wrote:
>> I have been trying to compile latest Bonmin 1.8.4, which includes Ipopt
>> 3.12.4, on Microsoft Visual Studio.
>>
>> I started with some older Visual Studio project files, which were working with
>> Bonmin 1.3.2, and received a lot of errors related to the symbols
>> BONMIN_BUILD, IPOPT_BUILD etc., which were not used in Bonmin 1.32.
>>
>> I was able to eliminate almost all the errors by suitable definition of these
>> symbols in the various projects, but there was one issue related to the
>> FORTRAN_INTEGER_TYPE symbol that remained..
>>
>> This symbol is defined (as int) in Ipopt\src\Common\config_default.h but not
>> in Ipopt\src\Common\config_ipopt_default.h. Therefore if IPOPT_BUILD is not
>> defined (as in the libBonmin project), there is a compilation failure in the
>> statement
>>
>> typedef FORTRAN_INTEGER_TYPE ipfint;
>>
>> which appears in Ipopt\src\Common\IpTypes.hpp
>>
>> Bottom line:
>>
>> There needs to be a definition of FORTRAN_INTEGER_TYPE in
>> Ipopt\src\Common\config_ipopt_default.h.
>>
>> I had a friend compile Bonmin/Ipopt on Linux, and the generated
>> Ipopt\src\Common\config.h and Ipopt\src\Common\config_ipopt.h both contain the
>> line
>>
>> #define FORTRAN_INTEGER_TYPE int
>>
>> I hope this simple fix to Ipopt\src\Common\config_ipopt_default.h can be made
>> in the next version.
>>
>> Otherwise the only way to proceed on Visual Studio without changing source
>> code is to put FORTRAN_INTEGER_TYPE=int in the preprocessor symbols of the
>> Visual Studio libBonmin project (or to define IPOPT_BUILD, which seems wrong).
>>
>> Thanks,
>>
>> David Wilkinson
>>
>> _______________________________________________
>> Ipopt mailing list
>> Ipopt at list.coin-or.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__list.coin-2Dor.org_mailman_listinfo_ipopt&d=DwICAg&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=BRcuJnQr5NAzU29t80hk2rsLc4vrlRySBDabuq0O1ZI&m=e1YnhT7r4i9cOl7LR5_nhR7e7CGsT9ApTdM5iMVV2kE&s=Y_xBYxIagB5RgeOvZqlLiV5bXamamGfxuqSszcjqPU0&e=
>>
>
>


More information about the Ipopt mailing list