On Thu, Jun 7, 2012 at 10:47 AM, Olaf Till <i7t...@t-online.de> wrote:
> On Thu, Jun 07, 2012 at 10:08:37AM -0400, Mike Miller wrote:
>> On Thu, Jun 7, 2012 at 8:19 AM, Olaf Till <i7t...@t-online.de> wrote:
>> > On Thu, Jun 07, 2012 at 02:04:06PM +0200, Lukas Reichlin wrote:
>> >>
>> >> On 07.06.2012, at 13:46, Olaf Till wrote:
>> >>
>> >> > On Thu, Jun 07, 2012 at 01:19:02PM +0200, Olaf Till wrote:
>> >> >> On Thu, Jun 07, 2012 at 01:05:49PM +0200, Lukas Reichlin wrote:
>> >> >>> On 07.06.2012, at 12:27, Olaf Till wrote:
>> >> >>>
>> >> >>>> Hi,
>> >> >>>>
>> >> >>>> recently there was a thread on the Octave Forge list, starting with
>> >> >>>>
>> >> >>>> http://sourceforge.net/mailarchive/forum.php?thread_name=6379301E-96D0-4AEF-BEEF-3DE7DD81A31F%40gmail.com&forum_name=octave-dev
>> >> >>>>
>> >> >>>> continued on the Octave maintainers list, starting with
>> >> >>>>
>> >> >>>> https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-June/028555.html
>> >> >>>>
>> >> >>>> due to installation of a package depending on Lapack failing on Apple
>> >> >>>> with a default Octave configuration. The reason is that mkoctfile
>> >> >>>> does
>> >> >>>> not understand the -framework switch.
>> >> >>>>
>> >> >>>> One conclusion was that passing the respective variables in
>> >> >>>> environment variables to mkoctfile could solve this problem.
>> >> >>>>
>> >> >>>> I've made this change to optim/src/Makefile and recommend similar
>> >> >>>> changes for all packages affected by this or a similar
>> >> >>>> problem. Example:
>> >> >>>>
>> >> >>>> MKOCTFILE ?= mkoctfile
>> >> >>>> LAPACK_LIBS := $(shell $(MKOCTFILE) -p LAPACK_LIBS)
>> >> >>>> BLAS_LIBS := $(shell $(MKOCTFILE) -p BLAS_LIBS)
>> >> >>>> LFLAGS := $(shell $(MKOCTFILE) -p LFLAGS) $(LAPACK_LIBS) $(BLAS_LIBS)
>> >> >>>> export LFLAGS
>> >> >>>>
>> >> >>>> or instead of the last line you could use a rule like
>> >> >>>>
>> >> >>>> %.oct: %.cc
>> >> >>>> LFLAGS="$(LFLAGS)" $(MKOCTFILE) -s $<
>> >> >>>>
>> >> >>>> I could take a look at other Makefiles, if necessary (list taken from
>> >> >>>> Marcos post: control, linear-algebra, octgpr, odepkg, optiminterp).
>> >> >>>>
>> >> >>>> Olaf
>> >> >>>
>> >> >>> Hi Olaf
>> >> >>>
>> >> >>> Please report if you have any improvements for the control makefile.
>> >> >>> Thanks!
>> >> >>>
>> >> >>> Lukas
>> >> >>>
>> >> >>
>> >> >> The attached short patch should do it in this case.
>> >> >>
>> >> >> Olaf
>> >> >
>> >> > Or wait please --- the one attached here should be a bit better
>> >> > (does not abolish user-specified libs).
>> >> >
>> >> > Olaf
>> >> >
>> >> > --
>> >> > public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net
>> >> > <control-src-Makefile.patch>
>> >>
>> >> Thanks Olaf, I applied your improved patch (SVN revision 10580).
>> >>
>> >> Best regards,
>> >> Lukas
>> >>
>> >
>> > As for the other mentioned packages, may I commit the attached patch?
>>
>> Hi Olaf, what's with the "?=" on all the assignments? I know what the
>> operator means, I am wondering what you intended vs using ":=" which
>> is more consistent and results in fewer subprocesses.
>>
>> --
>> mike
>
> I wanted to allow specification of this variables by a users
> environment variables. But I overlooked that ?= generates a
> recursively expanded variable as =. I changed it to use := and ifndef
> as attached.
I see. I usually recommend overriding make variables on the make
command line since this is the best guaranteed way to set the value of
a variable, and doing it this way means you can have normal
assignments in the Makefile without any special syntax. I think this
is more standard practice and regular users of make expect to have to
run
make "CFLAGS=$CFLAGS"
instead of expecting it to preserve their environment completely.
My 2cts.
--
mike
------------------------------------------------------------------------------
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
