[Ipopt] Ipopt config and FORTRAN_INTEGER_TYPE

Wed May 24 08:19:59 EDT 2017

Hi,

On 05/21/2017 01:29 PM, David Wilkinson wrote:
> Thanks, Stefan. When do you think the next release will be?

I don't know. You need this in a release?

> 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?

I guess that would be possible, but the defines that are made in the 
headers included from XyzConfig.h are sometimes necessary to have in the 
projects .hpp files. Therefore, it would not only require the COIN-OR 
projects .cpp files to include XyzConfig.h first, but also anyone using 
the COIN-OR codes. Thus, just changing this could break existing codes.
I don't think that this is worth the profit.

> 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.

The idea is that when building the code for project Xyz, then only 
XYZ_BUILD should be defined. That's what our buildsystem ensures.
They are used to distinguish between two versions of the configuration 
header files, one that has all defines that are needed to build a 
project, and one that has only those defines that are needed to build 
against that project. The latter is usually a subset of the former.
So using the former for all projects is ok as long as their are no 
conflicts, but I though that all of them define VERSION. Thus, if having 
all of them defined compiles for you, then that should be no problem.

Stefan

> 
> 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= 
>>>
>>>
>>
>>
> 

-- 
http://www.gams.com/~stefan