[Ipopt] Ipopt config and FORTRAN_INTEGER_TYPE

[David Wilkinson]

Hi Stefan:

Thanks for the response, and sorry for not responding sooner.

I think my client would want a released version.

I see that this whole issue is a bit more complicated than I thought. With the 
previous Bonmin 1.3.2 version that we were using, there were no IPOPT_BUILD, 
etc, macros, and having a mega-Bonmin project that built everything it needed 
except CoinUtils and Ipopt seemed OK (we did not do this ourselves; this was 
done in the project in Bonmin/MSVisualStudio that we adapted).

But as you say, if we do not receive any conflicts I think everything should be OK.

Thanks again. I really appreciate your conscientious tending of this mailing list.

David Wilkinson

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

Stefan Vigerske wrote:
> 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=
>>>>
>>>>
>>>
>>>
>>
>
>