[Monotone-devel] Re: automake sux

[graydon hoare]

Nathan Myers wrote:
> Graydon,
>
> This was supposed to show up on the list, but I haven't seen it...

I am guessing savannah is under attack from a worm or something. mail 
has about a 3 day lag getting through. compare the send vs. arrive time 
on anything you got from the list this week :(

> Maybe I can get Dave Abrahams (who did the jam work) to switch Boost
> over to scons, in some near-future release.  :-)

it seems unlikely to me, given all the work that went into bjam, but 
then they do have that affinity for python. who knows?

> That seems to do the job, except that it still complains 
>
>   $ aclocal
>   aclocal: configure.ac: 26: macro `AM_PROG_CC_C_O' not found in library
>
> However, it generated a configure script, which ran OK, and produced a
> Makefile, and the program built.  (It took a long time to build
> monotone-commands.o on my 300MHz P2 laptop.)  

I'll be working on trying to get compile time down a bit in the near 
future. I think I'm going to take a haitus from adding new features for 
a few months and just stabilize, optimize, and debug what we've got.

>  As it happens, I seem to have needed automake-1.7
> so your autogen.sh might not have worked anyway.  Better, perhaps, to 
> add instructions to your web page "building.html", including version
> requirements.  I wouldn't have thought to look for the autogen.sh.
> I did look for INSTALL, though, which is a good place to mention
> all this.

quite. we've had this concern before, it keeps being ignored. I've filed 
a bug on savannah.

> The build complained about lacking makeinfo, but proceeded.  You 
> already know what I think about info format documentation: I'd much 
> rather see the whole document and be able to scroll around in it, 
> than only get to see bits and bobs of it and have to poke fussily 
> around guessing what might be under which topic.  (Likewise for the 
> online docs.)  Can makeinfo be persuaded to throw it all into one
> long page?

there is such an option, and I actually already promised someone I'd put 
up the monotone docs online in such a form. then I forgot. filed a bug 
this time.

(I really do love getting suggestions, I am just very busy and 
forgetful. putting issues in the bug tracking system actually works 
somewhat -- I've closed 43 of the 86 bugs filed there)

> I got warnings in the cryptopp code about (e.g.) basecode.cpp:78,
> "statement has no effect", a macro expanding to a statement "0;".
> I think the common idiom is to pass "void(0)" instead of just "0",
> which quiets it in this case.  Maybe you don't want to introduce 
> deltas from the upstream source?  Also, warnings in iterhash.h 
> (member init order), rsa.cpp (funny use of virtual) and zinflate
> (various).  

yes, there are a lot of warnings in the support libraries. and that's 
just under 3.3, it gets unbuildable under the strict rules of 3.4. bug 
#6510 is about this.

> unspecified behavior), now announced to produce likely optimization 
> bugs.  I think you can turn that off with "-fno-strict-aliasing", 
> which might be preferable to "-O0".

curious, ok. bug #7892 is actually the source of the "-O0 on debian" 
build choice, but I've narrowed that down (just using a big shell loop) 
to cryptopp/integer.cpp. I now need to do more extensive probing to find 
out which method is actually failing in there.

> When I run the monotone I just built, it says the database schema it
> knows and the database I checked the source out of don't match.

that's a feature! it means we upgraded schema, and it's no longer safe 
to use the new monotone with the old db. you have two safe choices: 
"monotone db migrate" to run migration commands to move to the new 
schema, or revert to using the old monotone.

(note that, depending on which version you you built, one of the schema 
migration functions had a bug in 0.10. the version 
9fa1750d2c929f7fd3ce6cebba108904e1a39a82 does not have this bug anymore. 
I recommend building that.)

> By the way, I seem to be missing a key for 'oxygene at tastensuppe.de',
> whom I don't seem to find mentioned in the mailing list archives
> or on the web site.  ("monotone heads" complains.)

yes, it warns. it's just a warning, and in this case a harmless one 
since I approved of oxygene's change, which issued an identical cert 
bearing my signature.

possibly the UI is too scary when it warns you of unknown keys; maybe it 
should only warn when there's an unknown key and that unknownness is 
sufficient cause to reject a key during the trust evaluation phase. in 
your case, since I had signed the same cert, there was no rejection. 
maybe that's good enough not to warn. I've filed a bug on this.

> Apologies for being such a pest.

not at all! thank you for using it and exploring the rough spots. it's 
good feedback to get. makes me aware of what needs filing down and 
polishing.

I take user perception quite seriously; if it "feels awkward" to use, I 
consider that a bug. don't hesitate to file bugs in the BTS if you find 
something that feels awkward, even if there's no "logical" reason to 
think of it as a bug. perception is an important aspect of functionality.

-graydon