Re: trouble compiling

[Daniel J Sebald]

On 05/19/2012 09:30 AM, Mike Miller wrote:
> On Sat, May 19, 2012 at 5:12 AM, Daniel J Sebald<address@hidden>  wrote:
> > On 05/19/2012 12:33 AM, Jordi Gutiérrez Hermoso wrote:
> > > On 18 May 2012 15:18, Daniel J Sebald<address@hidden>    wrote:
> > > > On 05/18/2012 01:10 PM, Jordi Gutiérrez Hermoso wrote:
> > > > > On 18 May 2012 13:50, Daniel J Sebald<address@hidden>
> > > > >   wrote:
> > > > >
> > > > > > 1) Mild warnings in the configure file (i.e., warnings that don't
> > > > > > appear at the very end, but instead are only amongst a whole lot
> > > > > > of output) that really end up being needed in the default
> > > > > > compilation.  Here's an example:
> > > > > >
> > > > > > configure:59086: WARNING: I didn't find flex, but it's only a
> > > > > > problem if you need to reconstruct lex.cc
> > > > >
> > > > >
> > > > >
> > > > > I recently tried to alleviate this problem:
> > > > >
> > > > >      http://hg.savannah.gnu.org/hgweb/octave/rev/28e53daab1f8
> > > > >
> > > > > I thought I did make those warnings appear at the end all together.
> > > > > Am I wrong?
> > >
> > >
> > > > I'm not seeing anything stand out near the end of the file.
> > >
> > >
> > > Ah. Yeah. My bad. I broke that in 14605:28e53daab1f8. It's the first
> > > time I touch the build system, so please be forgiving. :-)
> > >
> > > Does this make it better?
> > >
> > >      http://hg.savannah.gnu.org/hgweb/octave/rev/8a84849ad986
> > >
> > > It would be great if you could test with various system configurations
> > > and let me know how it goes.
> >
> >
> > I uninstall the things that were causing problems the other day and went
> > through the configure process again.  It now does give warnings at the end
> > of the file.
> >
> > The output for the warning messages is a bit messy however.  It isn't
> > indented like the other warnings and there are several blank lines.  The
> > descriptions are a bit wordy for computer program output.  Could this be
> > modified as with the following examples?
> >
> >   AC_MSG_NOTICE([NOTE: Libraries or auxiliary programs may be skipped if they
> > are])
> >   AC_MSG_NOTICE([      not found OR if they are missing required features on
> > your])
> >   AC_MSG_NOTICE([      system. ])
> >
> >   OCTAVE_CONFIGURE_WARNING([flex not found.  Needed to reconstruct lex.cc,
> > such])
> >    AC_MSG_NOTICE([         as from VCS sources.])
> >
> >   OCTAVE_CONFIGURE_WARNING([bison not found.  Needed to reconstruct parse.cc,
> > such])
> >    AC_MSG_NOTICE([         as from VCS sources.])
> >
> > Would that work?  In addition to being a more condensed summary, it also
> > gets rid of the "but it's only a problem" phrase which I think makes the
> > warning sound insignificant.  Let the user interpret how important the
> > warning is to his or her situation.
>
> I'd be okay with the wording change.
>
> IMHO Octave is going above and beyond with these warnings and extra
> checks for maintainer tools.  The checks in configure and any warning
> messages it produces are mostly for users, not maintainers, who are
> strictly building from a properly released source tarball.  And those
> users don't need these maintainer tools to build Octave.

I don't completely agree with that.  It might be excessive in the case 
of common utilities like gperf (are those what you are calling 
maintainer tools? gperf, bison, etc.?), but there are many advanced 
packages like ARPACK and FFTW that I want to have knowledge about when 
building.  Building on a fairly fresh Fedora machine, I ran configure 
and went through step by step looking at the warnings and installing the 
missing packages.  It would have saved a day's time knowing:

1) That gperf, bison, flex were missing and would have ramifications on 
build.
2) That there is a "maintainer-clean" option to get out of the lex.cc snag.

I agree that the comments were geared for those building from a tarball, 
and what I proposed for comments may still be too directed to 
non-developers.  How about reducing it further to simply:

 OCTAVE_CONFIGURE_WARNING([flex not found.  Needed to reconstruct lex.cc.])

 OCTAVE_CONFIGURE_WARNING([bison not found.  Needed to reconstruct 
parse.cc])

For me (and maybe the two others a couple days ago caught by the same 
lex.cc/missing bison snag) just having that warning would have reduced 
my debugging by a few hours.


> > It might be nice to have a ./configure option that allows a more stringent
> > "maintainer" set of tests.  These would error instead of warn on the cases
> > the patch modified.  It isn't that necessary though if we could make
> > README.devel more descriptive.
>
> I'd vote for updating README.devel and/or HACKING over more configure options.
>
> I also want to point out that a lot of GNU projects work the same way
> and there might be some documentation already out there that Octave
> could reference or copy instead of reinventing.

Is "make maintainer-clean" a sort of GNU projects standard?  I'm alright 
with describing these things in README.devel, but a bit more verbose 
than the README currently is.  A project like Octave has new developers 
all the time.  Just within the past two weeks there have been several 
people inquiring about building and so on.

Also, HACKING isn't a file name I would look to as a developer.  That is 
where I would go if I ran into some obscure, non-standard problem and I 
needed to hack a solution.  For example, "To make Octave compile on 
Commodore Vic 64 you need to go to the /os/foo.asm file and change line 
35 from "in(aa4bit)" to "in(aa8bit)"".  That's a hack.  :-)

You seem to know quite a lot about GNU autotools/make.  I'll follow up 
with a post about flex and '-lfl'.

Dan