octave-maintainers
[Top][All Lists]
Advanced

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

Re: 2.9.11?


From: John W. Eaton
Subject: Re: 2.9.11?
Date: Wed, 25 Apr 2007 13:42:50 -0400

On 19-Apr-2007, Michael Goffioul wrote:

| On 4/19/07, John W. Eaton <address@hidden> wrote:
| > On 19-Apr-2007, Michael Goffioul wrote:
| >
| > | > > CC=cc-msvc CXX=cc-msvc AR=ar-msvc RANLIB=ranlib-msvc ./configure
| > | > > Would it be OK to use octave_config_info('config_opts') to achieve 
this?
| > | > > (I mean, is it OK for other platforms?)
| > | >
| > | For the time being, yes. But I could probably also use:
| > |
| > |    system(['cd src; ./configure ', octave_config_info('config_opts')]);
| > |
| > | although I didn't test it yet. But the point here is that I want to use 
the
| > | same flags as those used to compile octave itself. Adding *new* flags
| > | is something different.
| >
| > Shouldn't an Octave package use mkoctfile to compile things?  Aren't
| > the compiler options recorded in mkoctfile?
| 
| Yes they are, but the configure script still looks for a compiler if CC/CXX
| is not defined, leading to some assumptions for the configure tests. After
| some more checks, this should not be a problem, but still this is not "clean".
| Here's for instance what happens with the "image" package:
| - ./configure looks for a compiler in the following order: gcc, cc, cl
| - it finds cl (gcc is not in the PATH or not installed); hence the default
| object suffix is set to .obj
| - testing for a header like jpeglib.h tests its presence and usability; 
presence
| is OK, but usability is not: this is due to the fact that ./configure
| script tries
| to compile a file and test for the object file existence; at that
| point, CC has been
| redefined to cc-msvc (with "mkoctfile -p CC"), which by default produces .o
| object file; but the configure script looks for a .obj file and the
| test fails, leading
| to this kind of warning
| 
| configure: WARNING: jpeglib.h: present but cannot be compiled
| configure: WARNING: jpeglib.h: check for missing prerequisite headers?
| configure: WARNING: jpeglib.h: proceeding with the preprocessor's result
| configure: WARNING:     ## ------------------------------------ ##
| configure: WARNING:     ## Report this to address@hidden ##
| configure: WARNING:     ## ------------------------------------ ##

OK, how do you want to solve this problem?

BTW, the recommended way to run configure and set variables like CC,
CXX, etc. is

  ./configure CC=... CXX=...

Couldn't every invocation of configure that happens when building
Octave Forge packages use something like

  ./configure CC=$(mkoctfile -p CC) CFLAGS=$(mkoctfile -p CFLAGS) ...

?  Wouldn't this work on all systems, and shouldn't this be the
preferred way anyway so that the compiler used for building the
package is the same as was used for building Octave?

Maybe to save some typing and/or achieve some consistency there should
be a wrapper configure script that sets these options and calls the
real configure script?

jwe


reply via email to

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