My original thought was to just modify an existing build to make it more
suitable for Mac OS by modifying the embedded paths to the dynamic
libraries. But since some Unix-originated applications tend to have som
hidden path-dependencies as well, I was wondering about those.
To find any runtime linkage I would have to go through all the code and
doing that might take much more time than should really be necessary to just
confirm if my thought would work.
So what I'm basically wondering is, if it's possible to run Octave by simply
remapping all of it's library search paths or if it has any other
path-dependencies that might be useful to know about.
I could just try and remap everything but it would require some work so if
you come to think of any such problem area as described then please notify
me :)
2011/4/18 c. <[email protected]>
> Hi,
>
> First of all, if you are considering helping in making the Octave OSX
> binary better, you are very welcome!
>
> If you need help with this task you can continue asking questions on this
> mailing list but,
> if your questions are about the general Octave build system you will
> probably more easily find
> the support you need on <[email protected]> or [email protected].
> Also, if you are thinking about building a new binary for Octave you should
> be looking at a more
> recent version than 3.2.3, the latest available stable version is 3.4.0.
>
>
> On 18 Apr 2011, at 17:43, Mattias Nyberg wrote:
>
> > Hi.
> >
> > I'm having a look at the MacOS 3.2.3 package of Octave and the structure
> of it makes me wonder. Does it really need to look like that?
> >
> > I'm specifically wondering about the search paths for the dynamic
> libraries and why there's a flood of static libraries also in the package.
> >
> > About the search paths: Shouldn't it be possible to contain all the
> libraries in the application in a nicer way? Using "/tmp/deps-i386/" and a
> shell script is not really the mac way of packaging things as far as I know
> of.
> >
> > Do you have a specific reason for avoiding "@executable_path/xx"? Does it
> interfere with the ordinary build procedure or with how Octave functions,
> like runtime loaded dylibs?
> > Anyhow. I think Octave.app is really nice but the package makes it a bit
> problematic to use under certain circumstances I'd say.
> >
> > To sum up:
> > - Would a more macish packing procedure interfere with Octaves
> functionality in any way?
> > - The reason I ask is because I do know how to package applications on
> the Mac but I know nothing about the structure of Octave... yet :)
> >
> > I'd appreciate any assistance in this matter.
>
>
> The scripts that automatically build Octave.app are found in the
> source-forge repository here:
> <
> http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/admin/MacOSX/
> >
>
> As far as I can recall since the last time I looked at it, the main idea is
> to build Octave using the standard UNIX
> toolchain and then rely on platypus <http://www.sveinbjorn.org/platypus>
> to create the actual application bundle.
>
>
> > Thank you for your time
>
> Thank you for your interest in contributing to Octave!
> c.
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Octave-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/octave-dev
