[BuildTools] Question regarding header and type detection in CoinUtils

[Ted Ralphs]

Well, if int64_t is generally found in ctdint, then something strange is
going on. I will try to see what the situation is on other platforms when I
get back to this, but since

1. cstdint was not properly included in CoinTypes.hpp,
2. ctdint *was* included when testing for the existence of int64_t, and
3. none of the builds were broken,

this would seem to indicate that int64_t is either not found at all on most
platforms, i.e., cstdint is not found, or it is not found in cstdint.
Either way would be strange.

Cheers,

Ted


On Fri, Oct 3, 2014 at 10:31 PM, Miles Lubin <miles.lubin at gmail.com> wrote:

> <cstdint> is the standard C++ header file for int64_t. Are there platforms
> we support where this header doesn't exist?
>
> On Fri, Oct 3, 2014 at 11:24 AM, Stefan Vigerske <stefan at math.hu-berlin.de
> > wrote:
>
>> Hi,
>>
>> defining and exporting COINUTILS_HAS_CINTTYPES and
>> COINUTILS_HAS_INTTYPES_H and thus including the (c)inttypes(.h) header in
>> CoinTypes.h sounds best to me.
>> It's a bit complicated, as we already have HAVE_CINTTYPES and
>> HAVE_INTTYPES_H, but it seems to be clean and safe.
>>
>> While doing so, you could then also introduce COINUTILS_HAS_CSTDINT :-).
>> COINUTILS_HAS_STDINT_H was indeed added a year ago to fix some specific
>> issues.
>>
>> Stefan
>>
>>
>>
>> On 10/03/2014 04:47 PM, Ted Ralphs wrote:
>>
>>> Hi everyone,
>>>
>>> This e-mail is probably directed mostly at Stefan, but if anyone else has
>>> an opinion, feel free to weigh in.
>>>
>>> I'm trying to build CoinAll with Visual Studio 9 (we still need to
>>> support
>>> it because of Python extensions) on a new laptop running Windows 8 that
>>> also has Visual Studio 12 installed (yes, I know I'm asking for trouble).
>>> For reasons I cannot discern, the compiler is using a combination of the
>>> headers from both compiler versions (9 and 12), which may or may not be
>>> related to the issues I'm seeing. In a nutshell, code that builds fine on
>>> my old laptop now fails to build with the exact same compiler.This has
>>> caused me to dig into some stuff that I found does not completely make
>>> sense to me.
>>>
>>> The problem arises from the check for the type int64_t in the configure
>>> script for CoinUtils, which is done as so.
>>>
>>> AC_CHECK_TYPE([int64_t],[CoinInt64=int64_t ; CoinUInt64=uint64_t],[],[
>>> #ifdef HAVE_CINTTYPES
>>> # include <cinttypes>
>>> #else
>>> # ifdef HAVE_INTTYPES_H
>>> #  include <inttypes.h>
>>> # endif
>>> #endif
>>> ])
>>>
>>> The type int64_t is found at configure time (I think in the header
>>> cintypes), but only because the inttypes headers have been manually
>>> included for the test. In CoinTypes.hpp, these headers are *not*
>>> currently
>>> included and thus, the type is not found at compile time, which leads to
>>> an
>>> error.
>>>
>>> Adding the same block of code from the test above to CoinTypes.hpp fixes
>>> the problem for CoinUtils, but building Cbc then fails because the
>>> symbols
>>> HAVE_CINTTYPES and HAVE_INTTYPES_H are not exported to
>>> config_coinutils.h.
>>> If I export the symbols
>>>
>>> COINUTILS_HAS_CINTTYPES
>>> COINUTILS_HAS_INTTYPES_H
>>>
>>> then everything is fine. I have no idea why this was working fine in the
>>> recent past and now it suddenly causes a problem or why everything is
>>> fine
>>> on Linux and OS X. I suppose that type must be found in a different
>>> header
>>> on those OS's.
>>>
>>> Now my questions:
>>>
>>> 1. Another solution would be to check for the type int64_t without
>>> including the headers manually, which would then not require including
>>> them
>>> in CoinTypes.hpp. We would then just use long long instead of int64_t I
>>> suppose. I don't think this is the right solution, but I wanted to see if
>>> anyone had a different opinion.
>>>
>>> 2. This all made me realize that we have a block like this in
>>> CoinTypes.hpp.
>>>
>>> #ifdef COINUTILS_HAS_STDINT_H
>>> #include <stdint.h>
>>> #endif
>>>
>>> Why do we only check for stdint.h and not cstdint (as we do with
>>> inttypes).
>>> With the Visual Studio build, it is finding cstdint, not stdint.h, but
>>> then
>>> not including it. Of course, this is not causing a problem at the moment,
>>> but should we also export COINUTILS_HAS_CSTDINT? I haven't checked for
>>> blame, but I'm sure that code was inserted in there to solve some
>>> specific
>>> issue with finding types on some platform, but I guess that it would be
>>> more portable and correct if cstdint were also included when it's
>>> available.
>>>
>>> If you read this far, let me know what you think and sorry for the long
>>> and
>>> detailed mail!
>>>
>>> Cheers,
>>>
>>> Ted
>>>
>>>
>>>
>>> _______________________________________________
>>> BuildTools mailing list
>>> BuildTools at list.coin-or.org
>>> http://list.coin-or.org/mailman/listinfo/buildtools
>>>
>>>
>> _______________________________________________
>> BuildTools mailing list
>> BuildTools at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/buildtools
>>
>
>


-- 
Dr. Ted Ralphs
Associate Professor, Lehigh University
(610) 628-1280
ted 'at' lehigh 'dot' edu
coral.ie.lehigh.edu/~ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/buildtools/attachments/20141006/2fb4f626/attachment.html>