monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] compilation failure on Win32 MinGW


From: Stephen Leake
Subject: Re: [Monotone-devel] compilation failure on Win32 MinGW
Date: Thu, 30 Oct 2008 07:32:23 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (windows-nt)

Markus Wanner <address@hidden> writes:

> Hi,
>
> Stephen Leake wrote:
>> Is botan supposed to compile with anything other than Gnu compilers?
>
> Yes.
>
>> Agreed, but we should be clear on why upstream isn't adding "LL".
>
> Please check the botan-devel archive.

There's no search function at
http://lists.randombit.net/pipermail/botan-devel/, so that's rather difficult.

>> It doesn't actually "fail", since it's just a warning. But in my
>> experience, C warnings are bad, and should be fixed. So I always
>> compile under Emacs, which highlights warnings in the compiler output.
>
> Ah! So, please be more specific. 

Sorry. My personal policy is that warnings must be treated as
failures. It has saved me many headaches in the past.

> The warning is there on gcc on all platforms and should be ignored.

Then I suggest we put a comment in the code at that point saying we
are ignoring the warning, so this doesn't come up again.

>> What is the compiler actually doing for these constants (without LL)?
>> The warning implies it is truncating them to 32 bits, which would be
>> really bad.
>
> It doesn't truncate them, it's just an annoying and pedantic warning,
> AFAICT.

The problem with C compiler warnings is distinguishing the merely
annoying ones from the important ones. It's easy enough to eliminate
this warning; why make people wonder whether it's important or not?

>> Do we have unit tests that verify the compiler is doing the right
>> thing?
>
> No, why should we? It's a botan thing. Please concentrate on
> monotone ;-)

botan is a core component of monotone. If it doesn't work, monotone
doesn't work.

I don't trust _any_ compiler; that's what unit tests are for.

I guess we assume botan has its own test suite; those of us who are
paranoid should run it in addition to the mtn test suite :).

>>> All in all I'm really looking forward to nvm.stripped to get rid of
>>> these "custom build harness" issues. Do you mind test building that
>>> branch on MinGW?
>> 
>> Configure dies, with "error: Your lua library is not useable".
>> 
>> I don't have a MinGW Lua package installed. We'll need to update the
>> MinGW installation instructions on the Wiki. But apparently the Wiki
>> is moribund at the moment?
>
> nvm.stripped hasn't landed, yet, so I don't think updating the Wiki is
> the first thing to do. We (you?) first need to figure out how to compile
> nvm.stripped on MinGW, then we can document.

Well, we could add a "future process" section to the wiki. But this is
moot, since the wiki is currently not editable.

Perhaps the INSTALL doc in nvm.stripped would be a better place to
document the MinGW build process. or INSTALL.MinGW.

> Do you have a lua library at all? 

Only the one included in monotone. I'll try downloading the upstream
source and see what happens when I try to build it under MinGW.

> Maybe it should say: not found, instead of not usable? 

I think it's clear enough: I know I don't have a lua lib for it to find.


-- 
-- Stephe




reply via email to

[Prev in Thread] Current Thread [Next in Thread]