[BuildTools] Question regarding header and type detection in CoinUtils

Ted Ralphs ted at lehigh.edu
Fri Oct 3 10:47:46 EDT 2014


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

-- 
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/20141003/ad0ef82f/attachment.html>


More information about the BuildTools mailing list