Miguel, On 16 Oct 2013, at 13:00, Miguel de Benito Delgado <m.debenit...@gmail.com> wrote:
> Hi Massimiliano, > > On 13 Oct, 2013, at 22:29, Massimiliano Gubinelli <m.gubine...@gmail.com> > wrote: > >> By similar reasons in my opinion this should be the way things have to be >> done on Windows too. > > Isn't this more or less the case? Albeit less elegantly, because the whole > development environment is a zip instead of scripts to download and compile > oneself... > I do not follow the Windows development. I've taken the building scripts from the windows cross-compiler and I know that it is possible to bring up in this way an efficient cross-compiling environment. So there is no need for us to develop directly under windows. But of course the same strategy can be used to automate the creation of the zip file with all the updated libraries ready to use to develop directly under windows. >> For Unix machines one should rely on system libraries so have two versions >> of the same library installed should be considered not the common thing. > > Well, now that we are lagging almost 3 years behind the release of Guile 2, > most users will have to install an older guile than the default one in the > distro… but this is off the point. > Guile 2 is another problem but since scripts are not backward compatible with guile 1 I think most of the distros will retain the possibility of installing both. But I haven't checked. >> An option of course can also be to change all the configure to allow for >> exact paths of libraries but this will not solve the problem since you >> cannot ensure that a library which you call uses another copy of a library >> which you have linked in manually (for example think about guile and TeXmacs >> using different copies of gmp or libz, etc…). > > Good point. I was actually thinking about changing the configure to do > precisely that so I'm happy you told me this before. d'oh! > You can do it if you want, but I just mentioned that this will not avoid you to really take care of your developement environment (that is having fink, macports, user compiled libs all around is a bad bad idea....). >> So I think the easiest way to have a complete control of libraries (on Mac >> and Windows) is to recompile them locally with strict control of the >> building environment. > > Seems so, yes (but it'd still be nice to have a functioning configure script, > meaning one which actually uses the libraries it's told to. And any library > may be bundled within the .app package…). > I agree, if you look at the configure-tm script I actually override all the configure variables to drive configure to link my libraries and not others. But to enforce this you must to be sure to have a clear library path. And keep in mind that shared libraries are searched at runtime so the problem persist. If you run the bundle there is no problem since the scripts hardcode the path to the shared libraries so other libraries will not interfere. > Anyway, I'll try the tm-devel thing when I have time. You are quite right in > everything you say and I appreciate the effort put into the tm-devel stuff. > I have several machines so this was the less painful way to set up a developing environment on a clean machine in less than one hour. Moreover it support the creation of 32 and 64 bit libraries separately so that in principle we can use this to build universal app bundle, but to arrive at this there are few more obstacles to be solved. Best Max > Cheers, > -- > Miguel. > > > _______________________________________________ > Texmacs-dev mailing list > Texmacs-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/texmacs-dev _______________________________________________ Texmacs-dev mailing list Texmacs-dev@gnu.org https://lists.gnu.org/mailman/listinfo/texmacs-dev
