mkoctfile switch handling (was: Re: [OctDev] bug with optim-1.1.0.tar.gz and mac os 10.7.4)

[Olaf Till]

On Wed, Jun 06, 2012 at 02:38:50PM +0200, c. wrote:
> 
> On 6 Jun 2012, at 13:15, Jordi Gutiérrez Hermoso wrote:
> 
> > On 6 June 2012 05:11, Olaf Till <address@hidden> wrote:
> >> In this case it would possibly be more suitable to make mkoctfile
> >> understand -framework, at least at systems which need it. I think I'll
> >> ask that on the Octave maintainers list.
> > 
> > If you go this way, the problem is deeper than just -framework. It's
> > not an easy problem to deal with, because I would like to also accept
> > *all* compiler flags, such as -fexceptions and -std=c++0x, but the
> > problem here is: if you pass unrecognised flags, do you pass them to
> > the preprocessor, the compiler, the assembler or the linker? mkoctfile
> > really wraps all of those. You will notice that mkoctfile makes two
> > separate calls, one to compile and one to link. And whatever change
> > you make, you have to make sure you don't break existing uses of
> > mkoctfile that rely on the current buggy behaviour of accepting -W
> > flags as warnings, which is a mistake  I made once.
> > 
> > There's also the issue that we have two mkoctfile programs, one in
> > bash and one in C++.
> > 
> > I would like to see mkoctfile get fixed so that you and other Apple
> > enthusiasts can use it to your liking, but the problem seems difficult
> > to solve in general.
> > 
> > - Jordi G. H.
> 
> what about making separate scripts named 
> 
> octcc
> octcxx
> octf77
> octld
> 
> similar to what is done in openmpi?
> we could then keep mkoctfile as-is for backward compatibility 
> while transitioning to the new setup ...
> 
> 
> c.

Another possibility could be to let 'mkoctfile -p ...' return options
for the linker in the '-Wl...' form and options for some compiler in
the '-W...' form, so that it can accept them later.

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc
Description: Digital signature