[Context] minimals for cygwin
Hello, What do you (especially Mojca) think about adding cygwin to the supported architectures? I can patch first-setup.sh and the build-scripts and build the binaries. Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/
On Fri, Jul 16 2010, Mojca Miklavec wrote:
On Fri, Jul 16, 2010 at 16:40, Peter Münster
wrote: Hello,
What do you (especially Mojca) think about adding cygwin to the supported architectures?
I can patch first-setup.sh and the build-scripts and build the binaries.
I gladly add a new platform.
Ok, platform.sh is patched. And here the patch for first-setup.sh: @@ -54,6 +54,13 @@ i86pc) platform="solaris-intel" ;; *) platform="unknown" ;; esac ;; + # cygwin + CYGWIN*) + case "$cpu" in + i*86) platform="cygwin-32" ;; + x86_64|ia64) platform="cygwin-64" ;; + *) platform="unknown" ;; + esac ;; *) platform="unknown" esac Please notify me, when directories and authorization for me are ready, so that I can try a "do_all.sh" and later a "first-setup.sh". Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/
On Wed, Jul 21 2010, Peter Münster wrote:
And here the patch for first-setup.sh:
Hello Mojca, I've just seen, that I have the authorisation to modify first-setup.sh, so I applied the patch myself. Will it be available via rsync about 1h later? Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/
On 23-7-2010 9:14, Peter Münster wrote:
On Wed, Jul 21 2010, Peter Münster wrote:
And here the patch for first-setup.sh:
Hello Mojca,
I've just seen, that I have the authorisation to modify first-setup.sh, so I applied the patch myself.
just wondering, isn't it dangerous if anyone can change that script? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Fri, Jul 23 2010, Hans Hagen wrote:
just wondering, isn't it dangerous if anyone can change that script?
Hello Hans, What do you mean with "dangerous"? I don't think, that this will hurt or kill anybody or burn down your house... ;) With svn we can reverse-merge when I make errors! :-) Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/
On 23-7-2010 10:12, Peter Münster wrote:
On Fri, Jul 23 2010, Hans Hagen wrote:
just wondering, isn't it dangerous if anyone can change that script?
Hello Hans,
What do you mean with "dangerous"? I don't think, that this will hurt or kill anybody or burn down your house... ;)
well, it's a script, isn't it? so is access somewhat protected? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Fri, Jul 23 2010, Hans Hagen wrote:
well, it's a script, isn't it? so is access somewhat protected?
I suppose yes. Mojca can answer better I think. Peter -- Contact information: http://pmrb.free.fr/contact/
On Fri, Jul 23, 2010 at 10:39, Peter Münster
On Fri, Jul 23 2010, Hans Hagen wrote:
well, it's a script, isn't it? so is access somewhat protected?
I suppose yes. Mojca can answer better I think. Peter
First of all: it's not that everyone can modify the script. It's just the core team and Peter (I must have added him earlier at some time in order to do some other patches in binary building scripts). Second of all: one first needs to update the scripts with "svn up" and then run them when compiling the binaries. Peter, I gave you now the rights for the whole "minimals" tree. Until now you only had the rights for linux-64. You may try to run just ./bin_commit.sh ... if that works and if all the binaries have been successfully compiled. Once you add the binaries, I'll add the platform to all the other dozen of places where it's missing. And one more thing: we need the TL binaries as well. Are they available for both platforms? Mojca
On Fri, Jul 23 2010, Mojca Miklavec wrote:
Second of all: one first needs to update the scripts with "svn up" and then run them when compiling the binaries.
"svn up"? I thought that the recommended way was: rsync -av rsync://contextgarden.net/minimals/setup/first-setup.sh . This file has not been updated yet... Now I do: svn cat \ http://svn.contextgarden.net/minimals-src/arthur/first-setup.sh \
first-setup.sh
Peter, I gave you now the rights for the whole "minimals" tree. Until now you only had the rights for linux-64. You may try to run just ./bin_commit.sh ... if that works and if all the binaries have been successfully compiled. Once you add the binaries, I'll add the platform to all the other dozen of places where it's missing.
Compilation pdftex and xetex failed. I don't know why and unfortunately I don't have much time to care about that now. luatex is checked in.
And one more thing: we need the TL binaries as well. Are they available for both platforms?
Are the TL binaries different from the binaries in the minimals? I can only compile for cygwin-32 (no 64 bit here). Thanks for your efforts! Peter -- Contact information: http://pmrb.free.fr/contact/
On Fri, Jul 23, 2010 at 16:50, Peter Münster wrote:
On Fri, Jul 23 2010, Mojca Miklavec wrote:
Second of all: one first needs to update the scripts with "svn up" and then run them when compiling the binaries.
"svn up"?
I thought that the recommended way was: rsync -av rsync://contextgarden.net/minimals/setup/first-setup.sh .
I thought that we were talking about "platform.sh" file. Well, first-setup.sh is indeed a bit different and would have more influence than changing platform.sh, but other risks are more serious.
This file has not been updated yet...
Now I do: svn cat \ http://svn.contextgarden.net/minimals-src/arthur/first-setup.sh \ >first-setup.sh
I need to change a plenty of other things on the server as well anyway.
Peter, I gave you now the rights for the whole "minimals" tree. Until now you only had the rights for linux-64. You may try to run just ./bin_commit.sh ... if that works and if all the binaries have been successfully compiled. Once you add the binaries, I'll add the platform to all the other dozen of places where it's missing.
Compilation pdftex and xetex failed. I don't know why and unfortunately I don't have much time to care about that now. luatex is checked in.
It would be nice to figure it out, but I agree that getting luatex to work is more important.
Are the TL binaries different from the binaries in the minimals? I can only compile for cygwin-32 (no 64 bit here).
Yes. But 32-bit binaries used to be part of TL. If that's still the case, you don't need to do anything. I won't have time to do it today though (and I'll be occupied during the weekend). Mojca
On Fri, Jul 16, 2010 at 16:40, Peter Münster wrote:
Hello,
What do you (especially Mojca) think about adding cygwin to the supported architectures?
I can patch first-setup.sh and the build-scripts and build the binaries.
Peter, do you have anything against a slight shift of timeframe? I have just figured out something that I wasn't really aware of. Cygwin needs .exe files, so simply adding a platform won't work out of the box. I need to rewrite quite some bits of code if I want the automated scripts to start working. I could patch it now, but unless it's urgent, I would like to make a clean rewrite. In the meantime it would be great to get a patch to recognize cygwin incorporated into luatex and luatools, so that it will start working out-of-the-box once I fix the rest. Taco will tell if anything needs to be done about luatex binary. For luatools, take a look at the chunk of code that reads as below and try to patch it and send a patch to Hans: elseif os.type == "windows" then -- we could set the variable directly, no function needed here function os.resolvers.platform(t,k) local platform, architecture = "", os.getenv("PROCESSOR_ARCHITECTURE") or "" if find(architecture,"AMD64") then platform = "mswin-64" else platform = "mswin" end os.setenv("MTX_PLATFORM",platform) os.platform = platform return platform end elseif name == "linux" then function os.resolvers.platform(t,k) -- we sometims have HOSTTYPE set so let's check that first local platform, architecture = "", os.getenv("HOSTTYPE") or os.resultof("uname -m") or "" if find(architecture,"x86_64") then platform = "linux-64" elseif find(architecture,"ppc") then platform = "linux-ppc" else platform = "linux" end os.setenv("MTX_PLATFORM",platform) os.platform = platform return platform end elseif name == "macosx" then Mojca
On Tue, Jul 27 2010, Mojca Miklavec wrote:
do you have anything against a slight shift of timeframe?
Oh no, far from it! In fact, the support for cygwin is only a small gain in comfort: instead of using mswin's first-setup, compiling my own luatex.exe and replacing it, all would be done by cygwin's first-setup. I didn't know, that so much work was needed... :(
I have just figured out something that I wasn't really aware of. Cygwin needs .exe files, so simply adding a platform won't work out of the box. I need to rewrite quite some bits of code if I want the automated scripts to start working.
Are you sure? No special attention was needed in first-setup.sh and platform.sh. I was quite surprised, that "cp dir1/luatex dir2" copies "luatex.exe" under cygwin! I believe, that the only thing that is still needed to make cygwin work, are mtxrun and texlua in contextgarden.net/minimals/setup/cygwin/bin Then, at least mkiv should work.
In the meantime it would be great to get a patch to recognize cygwin incorporated into luatex and luatools, so that it will start working out-of-the-box once I fix the rest.
Taco will tell if anything needs to be done about luatex binary.
For luatools, take a look at the chunk of code that reads as below and try to patch it and send a patch to Hans:
Ok, I'll try it tomorrow (no ms-win at home, I'll do it at work). Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/
Hello Mojca, I hope, that I don't annoy you too much with the following idea: - we could ask the context-users, who needs support for cygwin (with loading of shared libraries) - if there is only one person (me), we can just drop cygwin from the list of supported platforms... (and I would add the recipe how to use mswin-mkiv under cygwin to the wiki) Peter -- Contact information: http://pmrb.free.fr/contact/
Peter Münster wrote:
I have just figured out something that I wasn't really aware of. Cygwin needs .exe files, so simply adding a platform won't work out of the box. I need to rewrite quite some bits of code if I want the automated scripts to start working.
Are you sure? No special attention was needed in first-setup.sh and platform.sh. I was quite surprised, that "cp dir1/luatex dir2" copies "luatex.exe" under cygwin!
If I recall correctly, the file still has to have a .exe extension for cygwin to be able to execute it, even though it tries hard to hide such un-unixy things. But maybe this limitation has been lifted under the newer versions of Windows?
In the meantime it would be great to get a patch to recognize cygwin incorporated into luatex and luatools, so that it will start working out-of-the-box once I fix the rest.
Taco will tell if anything needs to be done about luatex binary.
Not sure about 'needs to be done', but I iirc cygwin knows about symlinks, so a symlink from luatex[.exe] to texlua and texluac would be more efficient than the normal win32 solution. Best wishes, Taco
On Tue, Jul 27, 2010 at 20:17, Peter Münster wrote:
On Tue, Jul 27 2010, Mojca Miklavec wrote:
do you have anything against a slight shift of timeframe?
Oh no, far from it! In fact, the support for cygwin is only a small gain in comfort: instead of using mswin's first-setup, compiling my own luatex.exe and replacing it, all would be done by cygwin's first-setup. I didn't know, that so much work was needed... :(
It's not really "so much work", but it needs some special treatment in comparison to all other platforms since it has some exe files instead of files without any extension.
Are you sure? No special attention was needed in first-setup.sh and platform.sh. I was quite surprised, that "cp dir1/luatex dir2" copies "luatex.exe" under cygwin!
That's indeed nice. I'm surprised as well. But since it's not a cygwin server, I need to change some hardcoded file names.
I believe, that the only thing that is still needed to make cygwin work, are mtxrun and texlua in contextgarden.net/minimals/setup/cygwin/bin Then, at least mkiv should work.
I have set up some really basic support, but I'm almost sure that a whole lot of stuff fails (if nothing else, many binaries are missing just because the scripts "forget" about xetex.exe when they are instructed to copy just "xetex" etc.). You may try to run it and report how many things are still failing (you'll probably have to test in a month again). Mojca
On Wed, Jul 28 2010, Mojca Miklavec wrote:
I have set up some really basic support, but I'm almost sure that a whole lot of stuff fails (if nothing else, many binaries are missing just because the scripts "forget" about xetex.exe when they are instructed to copy just "xetex" etc.).
You may try to run it and report how many things are still failing (you'll probably have to test in a month again).
Ok, so we are really going to support cygwin (why the heck did I ask for that...???). Today, strange things happened, things that used to work, were suddenly broken: - metapost does no more build (no problem with 1.500, but 1.501 and 1.502 fail) - luatex 0.60.2 is dumping stack, so this message http://archive.contextgarden.net/message/20100715.110051.e7d65655.en.html is wrong now and I don't know, what has changed it's no problem for the pdf, but the exit code is no more 0, so context behaves like "context --once" and that's annoying Unfortunately I don't have time now, to look into the details... (my motivation for that is not so high, I just hope, that one day I'll no more need ms-win for my work...) Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/
On 07/28/2010 07:23 PM, Peter Münster wrote:
Today, strange things happened, things that used to work, were suddenly broken:
- metapost does no more build (no problem with 1.500, but 1.501 and 1.502 fail)
I need the error report if you want me too look at it (same for the luatex stack dumping) Best wishes, Taco
On Wed, Jul 28 2010, Peter Münster wrote:
Today, strange things happened, things that used to work, were suddenly broken:
And yet another problem: +--------------------------------------------------------------------- | Committing binaries for cygwin to SVN ... +--------------------------------------------------------------------- Sending current/VERSIONS Adding current/luatex/beta-0.61.0 Adding (bin) current/luatex/beta-0.61.0/luatex.exe Sending current/metapost/mpost.exe Transmitting file data ...svn: Commit failed (details follow): svn: Server sent unexpected return value (400 Bad Request) in response to MERGE request for '/minimals/bin/tex/cygwin/current' I tried several times, always the same message... Cheers, Peter P.S.: During the next 3 weeks, I won't have any contact with ms-win, so no cygwin-testing... -- Contact information: http://pmrb.free.fr/contact/
On Tue, Jul 27 2010, Mojca Miklavec wrote:
For luatools, take a look at the chunk of code that reads as below and try to patch it and send a patch to Hans:
Hello, Here a small patch that works for me: --- mtxrun-old 2010-07-30 12:17:07.019313600 +0200 +++ mtxrun 2010-07-30 12:18:24.615050000 +0200 @@ -1910,7 +1910,8 @@ -- we can use HOSTTYPE on some platforms -local name, platform = os.name or "linux", os.getenv("MTX_PLATFORM") or "" +local name, platform = os.name or "linux", os.getenv("MTX_PLATFORM") or +string.match(table.concat(arg, " "), " --platform=(.-) ") or "" local function guess() local architecture = os.resultof("uname -m") or "" Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/
participants (5)
-
Hans Hagen
-
Mojca Miklavec
-
Peter Münster
-
taco
-
Taco Hoekwater