octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suggested hg workflow


From: Jordi Gutiérrez Hermoso
Subject: Re: Suggested hg workflow
Date: Fri, 17 Jun 2011 13:59:52 -0500

2011/6/17 Daniel Kraft <address@hidden>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/17/11 19:29, Jordi Gutiérrez Hermoso wrote:
>> Daniel Kraft <address@hidden> wrote:
>>> I now finally really started coding for a first profiler attempt
>>> (although I will only have "full time" with holdiays in two weeks).
>>> Do you have tips on how I should manage this in my hg repository?
>>
>> You may want to use a new branch, but bear in mind that named branches
>> in hg are rather permanent. Each commit you make with a named branch
>> will have the branch name grafted on it. Bookmarks (an extension) may
>> be better suited. Work on the default branch in your own clone,
>> periodically merging your clone with Savannah locally, and put a
>> bookmark on your own changes of the clone.
>>
>> Does this make sense?
>
> Well, yes ... do you have a pointer to a page explaining how to do this
> (in commands) or something?  That would be great!

I think the hg wiki explains it:

     http://mercurial.selenic.com/wiki/BookmarksExtension

You understand how to merge, right? Do keep us periodically updated so
we can push your changes to Savannah, on the default branch.

> And something more:  Is there something you (or others, of course) can
> recommend on how to re-compile Octave after code modifications?

I've frequently whined about this in the past. The proposed solution
was "compile with hardware that has 16 cores". :-(

I don't think anything can be done. I've used ccache which gives me a
slight speedup. Also, don't compile with -O2 when you're debugging.
That also considerably slows down the compilation and is rarely
relevant while you're developing.

> Currently it is taking ages each time in the linker ... can this be
> avoided somehow?  Should I configure to build statically or something?

The things that the longest to link are the dynamically-linked oct
files which by design can't be statically linked. The rebuild time is
spent when you touch anything in the interpreter, which touches
liboctinterp, which every oct file links to. If you only touch files
under DLD-FUNCTIONS or script files, you won't spend as much time
rebuilding.

I have come to accept Octave build times as my moment of zen. While
Octave builds I ponder the state of the universe and the place
Octave's source code occupies in it. Strangely, I think it makes me
write better code. Reminds me of our ancestors who had to wait a month
to get their Fortran code to compile and run.

HTH,
- Jordi G. H.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]