monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Re: automake sux


From: Nathan Myers
Subject: [Monotone-devel] Re: automake sux
Date: Fri, 5 Mar 2004 20:55:05 -0800
User-agent: Mutt/1.3.28i

On Fri, Mar 05, 2004 at 04:30:37PM -0500, graydon hoare wrote:
> Nathan Myers wrote:
> >I've been trying to build 9fa17, and failing.  I'm using autoconf-2.59, 
> >aclocal-1.7 (which under nonrepeatable circumstances automake suggested 
> >running first), and automake-1.7.  Autoconf thinks it's happy, but
> >automake-1.7 says
> >...
> >Shouldn't we switch, wholesale, to Scons?
> 
> perhaps, but why ruin all the fun?
> 
> (j/k)
> 
> I have adopted the autotools as quasi "standards" because they are less 
> likely to surprise or annoy newcomers to the project. I want people to 
> have as few reasons to reject monotone as possible, even subconscious 
> ones like "something about building it was annoying". it is already the 
> case that about half emails I get about monotone relate to building 
> boost; I just find it intolerable to consider living without that.

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

> that said, I agree that scons is nicer than autotools. if you want to 
> whip up the appropriate SConstruct file as a counterargument, I may well 
> shift to using it. I am evaluating QMTest presently as a replacement for 
> autotest, for similar reasons. I just haven't made up my mind 
> completely. there are a lot of codgers for whom python is *less* well 
> understood than Makefile.am, not more. several of them are people I hope 
> to sway to using monotone :)

I can understand that.  Anyway I don't know scons any better than
autotools, yet, but this might be a good excuse to learn.

> anyways, for the time being I think the incantation you want is:
> 
> aclocal
> autoheader
> automake --foreign --add-missing --copy
> autoconf

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.)  

> since this is completely unintuitive, it seems to have become the 
> "standard" to put a file called autogen.sh in your build directory
> which runs these in order. I have one in mine, but I now notice I
> haven't added it to the manifest. shall I?

I have to admit knowing very little about the autotools -- if there's 
no ./configure, I have always just run autoconf and automake (I had 
thought that order was required!), and have never used aclocal or 
autoheader before.  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.

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?

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).  

Do you get those?  I'm using gcc-3.3.3 (prerelease).  In recent Gcc,
BTW, they introduced weird aliasing rules so you have to use unions in 
a way that the standard declares produces undefined behavior, instead 
of the traditional pointer casting tricks (which produced only 
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".

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.

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.)

Apologies for being such a pest.

Nathan Myers
ncm at cantrip.org




reply via email to

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