On Mon, Nov 28, 2005 at 04:43:06PM -0800, Paul Eggert wrote:
> Albert Chin <[EMAIL PROTECTED]> writes:
>
> > We tried this with gl_STDINT_H. However, the custom stdint_.h defines
> > uintmax_t which conflicts with gl_AC_TYPE_UINTMAX_T.
>
> That sounds like a problem that needs fixing anyway. And
Albert Chin <[EMAIL PROTECTED]> writes:
> We tried this with gl_STDINT_H. However, the custom stdint_.h defines
> uintmax_t which conflicts with gl_AC_TYPE_UINTMAX_T.
That sounds like a problem that needs fixing anyway. And I think the
following patch fixes it. Does this fix render the C/C++ is
On Mon, Nov 28, 2005 at 01:04:10PM -0800, Paul Eggert wrote:
> Albert Chin <[EMAIL PROTECTED]> writes:
>
> > I'm talking about _one_ project with two languages, C and C++. In
> > such a project, if human.h includes because of
> > HAVE_STDINT_H, how should a C++ source file #include "human.h"
> >
Albert Chin <[EMAIL PROTECTED]> writes:
> I'm talking about _one_ project with two languages, C and C++. In
> such a project, if human.h includes because of
> HAVE_STDINT_H, how should a C++ source file #include "human.h"
> correctly when isn't available to the C++ compiler?
Sorry, you'll have
On Sun, Nov 27, 2005 at 10:08:44PM -0800, Paul Eggert wrote:
> Albert Chin <[EMAIL PROTECTED]> writes:
>
> > We've currently solved it by implementing
> > separate defines depending on the language.
>
> That doesn't sound quite right. If you compile with different C
> compilers, or the same C co
On Sun, Nov 27, 2005 at 10:08:44PM -0800, Paul Eggert wrote:
> That doesn't sound quite right. If you compile with different C
> compilers, or the same C compiler with differing options, you should
> have to rerun 'configure'. The same sort of thing should occur if
> you compile with both a C an
