Re: [sage-devel] Re: Relocating Sage

2016-03-19 Thread Daniel Krenn
On 2016-03-18 09:46, Volker Braun wrote:
> On Friday, March 18, 2016 at 8:58:30 AM UTC+1, Daniel Krenn wrote:
> 
> .and recompile all Cython files and rebuild all the
> documentation on
> each of these new installations; this is not very convenient for
> developing (see thread [1]). 
> 
> 
> IMHO thats a minor inconvenience compared to compiling everything. Send
> a PR if it bothers you. 

But still a "minor inconvenience" of about one CPU hour or so for each
developer-installationan that for no reason...

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: Relocating Sage

2016-03-19 Thread Volker Braun
On Friday, March 18, 2016 at 8:58:30 AM UTC+1, Daniel Krenn wrote:
>
> .and recompile all Cython files and rebuild all the documentation on 
> each of these new installations; this is not very convenient for 
> developing (see thread [1]). 


IMHO thats a minor inconvenience compared to compiling everything. Send a 
PR if it bothers you. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: Relocating Sage

2016-03-19 Thread Daniel Krenn
On 2016-03-18 08:29, Dima Pasechnik wrote:
> Welcome to rpath Hell!
> But note that one can still install Sage from a binary install, this
> option did not disappear.
> Make an installation you can relocate, by using
> https://github.com/sagemath/binary-pkg. 
> Then install it as many times as you wish.

.and recompile all Cython files and rebuild all the documentation on
each of these new installations; this is not very convenient for
developing (see thread [1]).

Daniel

[1] https://groups.google.com/forum/#!topic/sage-devel/TDvduy8Vfyw

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: Relocating Sage

2016-03-19 Thread Jeroen Demeyer

On 2016-03-18 11:52, Volker Braun wrote:

file timestamps


Doesn't binary-pkg reset the timestamps to the original after modifications?

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: Relocating Sage

2016-03-19 Thread Dima Pasechnik
Welcome to rpath Hell!
But note that one can still install Sage from a binary install, this option 
did not disappear.
Make an installation you can relocate, by using 
https://github.com/sagemath/binary-pkg. 
Then install it as many times as you wish.


On Friday, March 18, 2016 at 3:11:00 AM UTC, David Roe wrote:
>
> Here's a use case where the recent changes to relocatability are really 
> annoying.  I'd like 6 sage installs in an SMC project so that different 
> groups at Sage Days 71 can work independently.  So I tried building a copy 
> from source and then copying it five times.
>
> Unfortunately, the relocation script is run at the end of the 
> installation, making it uncopyable.  This is despite the fact that I 
> refrained from starting Sage after building it.  Are there options 
> available other than building Sage six times?
>
> I haven't been following the issues involved very closely, but I would 
> really like to see this feature restored.  It's very useful for developing 
> Sage on servers.
> David
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: Relocating Sage

2016-03-19 Thread Dima Pasechnik


On Friday, March 18, 2016 at 7:58:30 AM UTC, Daniel Krenn wrote:
>
> On 2016-03-18 08:29, Dima Pasechnik wrote: 
> > Welcome to rpath Hell! 
> > But note that one can still install Sage from a binary install, this 
> > option did not disappear. 
> > Make an installation you can relocate, by using 
> > https://github.com/sagemath/binary-pkg. 
> > Then install it as many times as you wish. 
>
> .and recompile all Cython files and rebuild all the documentation on 
> each of these new installations; this is not very convenient for 
> developing (see thread [1]). 
>

this is a bug, IMHO...
Open a ticket,, fix it. :-)
Only complaining is not enough.



> Daniel 
>
> [1] https://groups.google.com/forum/#!topic/sage-devel/TDvduy8Vfyw 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: Relocating Sage

2016-03-19 Thread Daniel Krenn
On 2016-03-18 09:23, Dima Pasechnik wrote:
> On Friday, March 18, 2016 at 7:58:30 AM UTC, Daniel Krenn wrote:
> .and recompile all Cython files and rebuild all the
> documentation on
> each of these new installations; this is not very convenient for
> developing (see thread [1]). 
> 
> this is a bug, IMHO...

I would guess so.

> Open a ticket,

Done. https://github.com/sagemath/binary-pkg/issues/4

> , fix it. :-)

:)

> Only complaining is not enough.

...but as there hasn't been any answer/comment to the other posting,
I've brought it up again here...

Daniel

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: Relocating Sage

2016-03-18 Thread Volker Braun
On Friday, March 18, 2016 at 11:25:36 AM UTC+1, Dima Pasechnik wrote:
>
> The question is what precisely triggers the rebuild of cython files (== 
>  rebuild of all python extensions, I presume?)
>

file timestamps

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: Relocating Sage

2016-03-18 Thread Dima Pasechnik
as a workaround to speed it up it should be possible to copy the ccache 
created while building the distributive.

The question is what precisely triggers the rebuild of cython files (== 
 rebuild of all python extensions, I presume?)
 

On Friday, March 18, 2016 at 8:46:40 AM UTC, Volker Braun wrote:
>
> On Friday, March 18, 2016 at 8:58:30 AM UTC+1, Daniel Krenn wrote:
>>
>> .and recompile all Cython files and rebuild all the documentation on 
>> each of these new installations; this is not very convenient for 
>> developing (see thread [1]). 
>
>
> IMHO thats a minor inconvenience compared to compiling everything. Send a 
> PR if it bothers you. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: Relocating sage

2016-02-05 Thread Volker Braun
You need a unique string to search&replace, and after moving from 
/verylonguniquepath to / you've lost that uniqueness. So to undo you'd have 
to store the state how it was before patching in some external file. 
Possible but extra code paths that need to be written and tested...

On Friday, February 5, 2016 at 9:08:56 AM UTC+1, Dima Pasechnik wrote:
>
> By the way, I do not see why the present binary patchning procedure cannot 
> get an undo mode. Then it can be used many times, to move things around.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: Relocating sage

2016-02-05 Thread Jeroen Demeyer

On 2016-02-05 09:08, Dima Pasechnik wrote:

By the way, I do not see why the present binary patchning procedure cannot get 
an undo mode.

It's not technically impossible, just more work to implement I guess.

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: Relocating sage

2016-02-05 Thread Dima Pasechnik
By the way, I do not see why the present binary patchning procedure cannot get 
an undo mode. Then it can be used many times, to move things around.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: Relocating sage

2016-02-04 Thread Jeroen Demeyer

On 2016-02-05 01:44, John H Palmieri wrote:

run the relocation script.


There is no such thing anymore. Sage can no longer be relocated.

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: Relocating sage

2016-02-04 Thread John H Palmieri


On Thursday, February 4, 2016 at 3:43:47 PM UTC-8, Volker Braun wrote:
>
> On Friday, February 5, 2016 at 12:24:27 AM UTC+1, John H Palmieri wrote:
>>
>> Should the model when building from scratch be
>> ./configure --prefix=/target/location
>> make
>> make install
>>
>
> This basically doesn't work if you compile your own dependencies; You have 
> to "make install" you dependencies before you can use them in later stages 
> of "make".
>

I guess that I'm asking whether "make install" should just copy the 
appropriate parts and then run the relocation script. That is, we have a 
way of installing Sage, so why not make it a make target?
 

>
> It can work for sage-the-library only, and we should aim for that 
> eventually. 
>
> For sage-the-distribution not so much. There is a long list of desirable 
> things that our current build system can't do: No reliable incremental 
> builds, no modular binary packages, ... One possibility would be to use 
> hashdist for our source builds and extend it to produce conda-compatible 
> binary packages (as Aron proposed before) for private $HOME installs. And 
> publish our own rpm/debs for system-wide installation, possibly using 
> distro packages for dependencies when possible.
>

Same question here.

-- 
John
 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: Relocating sage

2016-02-04 Thread Volker Braun
On Friday, February 5, 2016 at 12:24:27 AM UTC+1, John H Palmieri wrote:
>
> Should the model when building from scratch be
> ./configure --prefix=/target/location
> make
> make install
>

This basically doesn't work if you compile your own dependencies; You have 
to "make install" you dependencies before you can use them in later stages 
of "make".

It can work for sage-the-library only, and we should aim for that 
eventually. 

For sage-the-distribution not so much. There is a long list of desirable 
things that our current build system can't do: No reliable incremental 
builds, no modular binary packages, ... One possibility would be to use 
hashdist for our source builds and extend it to produce conda-compatible 
binary packages (as Aron proposed before) for private $HOME installs. And 
publish our own rpm/debs for system-wide installation, possibly using 
distro packages for dependencies when possible.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.