Windows Support #1
Conversation
|
Hi,
Sizhe Zhao ***@***.***> wrote:
-- Commit Summary --
* otf.c: Fix compilation on Windows
Thanks for the patch.
Do other Neatroff programs compile on Windows?
Ali
|
|
Yes, though there are still some problems to be fixed. I'm working on that. |
|
Sizhe Zhao ***@***.***> wrote:
Yes, though there are still some problems to be fixed. I'm working on that.
What do you think of making neatroff work on windows?
I wonder how big the changes are.
I am not much familiar with Windows; is this for building
Neatroff natively or using Cygwin?
I also wonder if there are many that use Neatroff on Windows.
Ali
|
|
Natively. Since it can already compile for Windows, I would say the code won't need to change too much. The problems left are probably path handling, encoding handling, and relocatability support. |
|
The changes in this very PR is enough to compile it on Windows. |
|
Sizhe Zhao ***@***.***> wrote:
The changes in this very PR is enough to compile it on Windows.
How about other Neatroff programs? If the amount of required changes
are large, I think it is cleaner to maintain a Windows port in
separate branches.
Thanks,
Ali
|
|
Other programs can be compiled without change. However, work are required to make them work properly. |
|
Sizhe Zhao ***@***.***> wrote:
@Prince213 pushed 1 commit.
9673b2b otf.c: Set stdin to binary mode on Windows
Thank you very much.
To make the code base simpler, I think it helps to concentrate
on POSIX, only. We can keep the changes required to build
neat* natively on Windows in separate branches, which are
kept up-to-date with the master branch; we can add a link
to this branch in README. I think all of neatroff, neatpost,
and neatmkfn (and probably neatroff_make) need to be changed.
Is there an easy way of keeping all changes in a single
repository?
Ali
|
|
Instead of maintaining separate branches or repos, I would suggest creating a platform abstraction layer. You can extract POSIX-related code to a separate file, implement OS-independent functions with POSIX-specific code, and use those functions instead. This can make the code more portable and focus on logic itself. |
No description provided.