On 6 Jun 2012, at 13:15, Jordi Gutiérrez Hermoso wrote: > On 6 June 2012 05:11, Olaf Till <i7t...@t-online.de> 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. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
