Re: GSoC project

[PhilipNienhuis]

PMFJI


Michael Goffioul wrote
> On Sun, Jun 16, 2013 at 1:34 AM, Anirudha Bose <

> ani07nov@

> > wrote:
> 
>> On Sun, Jun 16, 2013 at 2:02 AM, Michael Goffioul <
>> 

> michael.goffioul@

>> wrote:
>>
>>> On Sat, Jun 15, 2013 at 1:41 AM, Anirudha Bose &lt;

> ani07nov@

> &gt;wrote:
>>>
>>>> Hi Michael. My build process was interrupted because of a small bug in
>>>> older versions of tex2dvi. I have CC'ed you the issue I had discussed
>>>> with
>>>> jwe. I had to do a small change in the file tex2dvi and now I am
>>>> compiling
>>>> octave again.
>>>>
>>>> The time taken to compile octave (till I get the error) is close to 200
>>>> minutes (this is why I have to wait so much to see any result, which
>>>> maybe
>>>> be a build failure). I am expecting to finish it soon.
>>>>
>>>
>>> Compiling octave is long, but 200 minutes seems quite a lot, if you're
>>> compiling under Linux (even cross-compiling) with a decently recent
>>> computer. FYI I'm using a dual P4 3GHz from 2008, so it's not really
>>> new,
>>> though I don't think it takes more than 3 hours to compile octave. You
>>> might want to increase the number of "make" jobs to use parallel
>>> compilation.

For reference, on a Lenovo laptop with a core i5, cross-compiling (only)
Octave with JOBS = 4 takes about 25 minutes incl. download, bootstrap,
configure & building.
But on native (=under Windows) MingW, multiple make jobs don't work, so I'd
be looking at 2 hours (120 mins) there.


>>>> Meanwhile, I have taken a look at your patch in the attachment
>>>> msvctools-libiconv.bz2 to jwe and tried to make sense out of it
>>>> referring
>>>> to your old mail on the efforts previously done to cross-build octave
>>>> for
>>>> Windows.
>>>>
>>>
>>> This is basically trying to port my build script for MSVC to MXE. This
>>> is
>>> a bit out of the scope of your GSoC project. MSVC it nos part of the
>>> "officially" supported compilers for octave. You should focus on
>>> GCC/MinGW.
>>>
>>> Next week starts the first coding session. I'd like you to define clear
>>> goals for this first session, so that we know where we're going. So far
>>> it
>>> seems that MXE is a good candidate, at least for native Linux, native
>>> MinGW, cross MinGW. There are already a few people heavily working on
>>> making it work for native MinGW and cross MinGW, so IMO your focus
>>> should
>>> be among those:
>>> 1) get quickly up to speed with native MinGW and help polishing the last
>>> bits not working
>>>
>>
>> jwe's update said that the dependencies missing in his fork of MXE are
>> ghostscript, pstoedit, fig2dev, and Java. The dependency pstoedit has
>> already been added (see the list of dependencies in my blog update [1]).
>> Should I start my work on adding the remaining of these dependencies?

After glancing through that list I have a few remarks:

- There are a number of  "of-***" dependencies which are octave-forge
packages. Octave is not really depending on those, they're just add-ons.
They do no harm but IMO you can ignore these for the time being, it is very
easy to add more of those later on.

- libodbc++, freetds, postgres and sqlite turn out not to be needed at all.
I've just added a patch to the patch tracker to remove them from mxe.

- I've been busy trying to add Java and LLVM in the MXE builds. The
stumbling block is that changing configure options for Octave itself leads
to build errors, maybe related to cross-compiling. 
Java had probably best be added once building with MinGW/MXE works natively
on Windows. llvm is already built in MXE but somehow it doesn't get included
in Octave itself.


> The ones that comes to my mind:
> - llvm (it's part of MXE, but is it enabled in your build?): I know JIT
> support is still experimental, but I don't see any harm in enabling it

See above


> - OpenBLAS: I don't see it in MXE, though the gain is huge compared to
> reference BLAS implementation
> - ATLAS: though I'm not sure it's useful if OpenBLAS is used

I've already looked at OpenBLAS, perhaps that's another candidate for
building natively in Windows with MinGW/MXE. 
Note that not all systems seem to run reliably with OpenBLAS. Nitzan has
included a number of blas implementations for some architectures in his
MinGW binaries to overcome this issue.


> - octave-forge packages: I see a few of them in MXE, but there's much more
> than that; some packages will introduce new dependencies (especially
> packages like zenity or video)
> 
> 
>> [1] http://wp.me/p3D9SG-c
>>
>> 2) implement a user-friendly installer for Windows; here my suggestion is
>>> to re-use (and re-engineer) the installer I used to use for my MSVC
>>> binaries
>>>
>>
>> Can you give me some resources of the installer you had used earlier?

In MXE there's already a basic installer (NSIS) built in (see #8051 in the
patch tracker). In Octave-Forge there's an older NSIS build script for the
3.2.4 Octave binary, see:
http://sourceforge.net/p/octave/code/HEAD/tree/trunk/octave-forge/admin/Windows/mingw32/octave.nsi.in
 


> I've update the archive containing all my build scripts at:
> 
> https://dl.dropboxusercontent.com/u/45539519/octave-build2.zip
> 
> The installer scripts are in modules/octaveinst. Yout starting point
> should
> be octaveinst.sh (which is called by my main build.sh script, but you
> shouldn't worry about that). The script will generate the base NSI file as
> well as other NSI files for octave-forge. The installer allows various
> things like:
> - selection of modules
> - selection of octave-forge packages
> - resolve dependencies between octave-forge packages
> The script has also a secondary mode whereby it's able to generate an
> installer for a single octave-forge package. I use this mainly to upgrade
> existing packages (or add new ones), without regenerating the full octave
> installer.
> 
> 
>> Can we do something so that Windows users do not have to install
>> MinGW/MSys or Cygwin to run Octave? If MinGW or Cygwin is indeed
>> necessary
>> to run Octave (haven't checked yet), then perhaps we can include their
>> installers as a part of our setup.

In MXE, when cross-compiling from Linux, a complete MSYS environment is
built together with the native (= MinGW/Windows) gcc compilers and all
dependencies needed to build binary packages. In fact, the current setup of
MXE is that all the included OF packages included in the MXE build are to be
built (incl. compiled) only after MXE-Octave has been installed in Windows.
On Windows it hasn't been possible yet to build the native gcc compilers,
but it is still an ambition.

OK it takes up a bit of disk space [1] (should be no big deal these days)
but it is very convenient for the majority of potential Windows users to
have this build environment already present in their Octave installation.
For the developers there's an advantage too: user support, debugging and
solving problems gets a lot easier if the included build tools are
standardized.

[1] Today's cross-compiled MXE binary takes up around 500 MB after
installation in Windows. This includes a build environment sufficiently
complete for binary octave-forge packages (provided these do not need
additional dependencies).


> As Marco said, Cygwin is handled separately. Cygwin has its own package
> management system. For the native Windows binaries, MinGW/MSYS is not
> actually needed to run octave. Though there are a few components that are
> mandatory, like less or makeinfo, and there are (should be) bundled into
> the binary. The full MSYS shell is required when you want to compiles
> things for octave: then you need a shell (for running "pkg" command) or a
> compiler (to run mkoctfile). If you look into the installer I used to
> produce, you'll see the the MSYS component is optional, in case the user
> already has MSYS installed and want to use it.

I estimate MSYS + build tools in MXE binaries only take around 200, maybe
300 MB disk space after installation.

Philip




--
View this message in context: 
http://octave.1599824.n4.nabble.com/Re-GSoC-project-tp4654312p4654329.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.