Hello, The attached patch detects if LuaTeX is compiled under cygwin: the result of os.type is unix and os.name is cygwin. Without this patch, os.type is unix and os.name is generic... Is this patch ok or would you prefer os.type to return windows? I think it's best this way. Anyway, as most users will use binaries compiled under non-cygwin in their cygwin system, thus it does not solve the cygwin detection problem. Thank you, -- Elie
Élie Roux wrote:
Hello,
The attached patch detects if LuaTeX is compiled under cygwin: the result of os.type is unix and os.name is cygwin. Without this patch, os.type is unix and os.name is generic... Is this patch ok or would you prefer os.type to return windows? I think it's best this way.
Patch applied as-is. 'cygwin' sounds fine as a name. Best wishes, Taco
On 17 March 2010 09:55, Élie Roux
Anyway, as most users will use binaries compiled under non-cygwin in their cygwin system, thus it does not solve the cygwin detection problem.
But if non-cygwin binaries are used, why would you want to detect cygwin at all? The best you can do is to detect if cygwin is installed on the system, but that doesn't mean that you want to run under cygwin. Wasn't cygwin added as a separate ARCH in TL to clear this confusion? Cheers, Tomek
2010/3/17 T T
But if non-cygwin binaries are used, why would you want to detect cygwin at all?
Because that's what I'm using, and thus I guess I'm not the only one ;-)
The best you can do is to detect if cygwin is installed on the system, but that doesn't mean that you want to run under cygwin. Wasn't cygwin added as a separate ARCH in TL to clear this confusion?
I don't know, but I'm using LuaTeX binaries cross-compiles by Taco at each releases (again, I'm definitley not the only one), and I need to change cygwin paths returned by fc-list (the fc-list of cygwin)... Soon I'll start to compile my own binaries under cygwin, but I don't think we can expect everyone to do so. Is the cygwin ARCH of TL compiled under cygwin? If so, my patch will make things work better, as we'll know that unix/cygwin is cygwin (which we couldn't with unix/generic). Thank you, -- Elie
On 17 March 2010 12:18, Élie Roux
2010/3/17 T T
: But if non-cygwin binaries are used, why would you want to detect cygwin at all?
Because that's what I'm using, and thus I guess I'm not the only one ;-)
The best you can do is to detect if cygwin is installed on the system, but that doesn't mean that you want to run under cygwin. Wasn't cygwin added as a separate ARCH in TL to clear this confusion?
I don't know, but I'm using LuaTeX binaries cross-compiles by Taco at each releases (again, I'm definitley not the only one), and I need to change cygwin paths returned by fc-list (the fc-list of cygwin)... Soon I'll start to compile my own binaries under cygwin, but I don't think we can expect everyone to do so.
Ah, OK. Well, if you want the binaries to understand cygwin intricacies then you have to compile them under cygwin I reckon.
Is the cygwin ARCH of TL compiled under cygwin?
This is my understanding. Ken Brown is maintaining this port, perhaps you should ask him or on tlbuild for more information/help. I don't use cygwin myself and know very little about it (if I'll ever need unix under windows I'll go for VBox or andLinux, cygwin is a strange beast).
If so, my patch will make things work better, as we'll know that unix/cygwin is cygwin (which we couldn't with unix/generic).
No worries. These changes will pulled to TL along with all the others once we start building for the next release. Cheers, Tomek
participants (3)
-
T T
-
Taco Hoekwater
-
Élie Roux