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. > I committed this change over the weekend, because I wanted to fix > those warnings in nvm.resolve_conflicts. > > I'll take them back out for now. Good. >> but this currently means compiling all of the 3rd party libraries >> with "-fpermissive". > > Which means we're giving up a lot of compiler checks; that doesn't > seem like a good idea. Agreed. nvm.stripped helps that. AFAICT Jack thinks of it as gcc being overly pedantic. In that case, I absolutely agree with him. > In general the autoconf stuff can handle per-file compiler options. > But that may be a pain to implement for this. Yes, having done the recent integrated-botan upgrades, I strongly recommend against such a thing. Botan itself doesn't use autoconf. > 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. The warning is there on gcc on all platforms and should be ignored. > With all the LLs in place, and removing -fpermissive, it compiles > without warning or error. Sure. > 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. > 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 ;-) >> I've committed the changes to Makefile.am with minor adjustments and >> some comments on these exceptions. Thanks for your report and please >> test again. > > It compiles fine now. Cool, thanks for testing. >> 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. Do you have a lua library at all? Maybe it should say: not found, instead of not usable? The m4 scripts aren't overly clever, yet. I was hoping some m4 wizard could pick up and help, because I'm not particularly found in m4. > I'll have to get my MinGW buildbot back on line; the video output > died, so I need to get a new computer. Having a MinGW buildbot would certainly be cool. Regards Markus Wanner _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel