octave-maintainers
[Top][All Lists]
Advanced

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

Re: trouble compiling


From: Daniel J Sebald
Subject: Re: trouble compiling
Date: Fri, 18 May 2012 15:57:33 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 05/18/2012 02:36 PM, Mike Miller wrote:
On Fri, May 18, 2012 at 3:05 PM, Daniel J Sebald<address@hidden>  wrote:
OK, thanks Doug.  These past two emails have motivated me to go back and run
"make clean".  After doing so, I see that lex.cc is still present. So that
is where a problem lies.

Hi Dan,

Did you try "make maintainer-clean"?  I have not tested with Octave
yet, but that is its purpose in the GNU build system.

OK, that appears to be the solution that Doug and I were missing, thanks. And much preferred over what Luca described.

I did a grep on 'maintainer-clean' in the source tree and see that it is in fact described in the INSTALL. I think INSTALL is where I first looked, but my attention was drawn to the /etc directory and the READMEs and HACKING at which point I felt I had the info I needed. This is probably because of this sentence in INSTALL:

"The following more-detailed instructions are generic; see the `README' file for
instructions specific to this package."

Nonetheless, had I read this sentence at the start:

  6. [snip]  There is
     also a `make maintainer-clean' target, but that is intended mainly
     for the package's developers.  If you use it, you may have to get
     all sorts of other programs in order to regenerate files that came
     with the distribution.

I think it wouldn't have sunk in that I'd need 'maintainer-clean' at some point. Having gone through the lex.cc snag the sentence makes sense now.

Since most of the HACKING contents is really geared for developers, I'd like to propose that HACKING be absorbed in the file README.devel to make README.devel the go-to file for developers. We could add the description Jordi gave for placing the object code in a different directory. We could include a "Summary of Commands Developers Will Need" in which we summarize, e.g.,

./autogen.sh
First step in building from archived source code. Autogen is a shell script that prepares...

./configure
Second step in building from archived source code; first step in building from tarballed source code. Configure will check the system for necessary or optional libraries and utilities and issue warnings that are summarized on the screen and in a 'config.log' file. There are several options that can be include with the command line to configure Octave in ways different from the default. Configure will convert many files (e.g., *.ll) to source code (e.g., *.cc) that may be compiled in the follow up make process.

./make
Once the source tree is prepared and then configured, 'make' will traverse the source tree compiling all source code into object files then assemble all object files into an executable file (Octave).

./make test
Run the series of test that comes with Octave to check the integrity of its operation and associated script files.

./run-octave
Run Octave locally without installing the software for broader system access.

./make install
Install the Octave program so that it has wider access on the computer system for others to use.

./make clean
Remove the program binaries and object files from the source code directory.

./make distclean
Remove the the files that `configure' created except those as a result of translating and might otherwise appear in a released tarball. Removing such files with this command would cause problems source code where per-translated files (e.g., *.ll) are not present. See 'maintainer-clean' for more extensive cleaning.

./make maintainer-clean
The most thorough cleaning option is "maintainer-clean" bringing the source tree back to the pre-configure state. This removes all translated files (e.g., *.cc files created from *.ll files) and Makefiles as though ./configure has not yet been run. If this option of make is run, a second invocation will not work because the Makefile itself will have been successfully removed. This is the preferred cleaning process for developers experimenting with code and creating patches for the source archive as it ensures catching any overlooked bugs introduced to the build process.

Dan


reply via email to

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