[Top][All Lists]
[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