Excuse me, but are you saying it's the responsibility of one Open Source
project to sort out the vagaries of all the development tools a
user might want to install on their PC? I don't agree. I think it is up to each individual to manage what they install on their PC. If you think you have some ideas about how to configure a PC running Microsoft Windows, then by all means volunteer to do something.
First let me express my gratitude for the many OpenCobol developers. I realize OSS is a community process, and I realize the work that has been put into OpenCobol. It is not my intention to deride that work. I'm glad that Sergey, Gary, and others have been working towards better support for Windows.
As I understand it,
OpenCobol support for the difficult platform called Microsoft Windows is
a recent development, probably for exactly the reasons you have
been encountering.
Yes, Windows is incredibly cumbersome to develop on, even more so for projects originally geared towards POSIX environments. But I think that the OpenCobol community should make the effort to support Windows anyway, because being a multiplatform programming language is worth it.
You must have also realised that this is a project undertaken by volunteers, not a product you have paid for. So maybe
you should lecture Microsoft for not supplying decent
development tools with their operating system - GNU/Linux distributions do that for free...
That's a fair point, Microsoft is largely to blame. But plenty of other programming languages have released one-click installers that require zero configuration on the user's part, automatically add their binaries to PATH, do not collide with binaries from other systems, and know where their own INCLUDE directories are. As much as I hate Microsoft's antiPOSIX practices, it's not Microsoft's fault that OpenCobol has these configuration problems. It's the result of A) most OpenCobol development being done in a *nix environment, reducing the desire for a Windows installer, let alone Windows binaries and B) Cobol's build process requiring external compilers due to using C as an IR, where most other programming languages use a different compilation process.
In short, /usr/loca/include/OPENCOBOLSTUFF works in Unix because that's standard in Unix. This can work in Windows, but the cpp.exe included in Gary Cutler's installation files must be reconfigured to look for the includes directory as a sister directory to bin, where cobc.exe and cpp.exe live. Perhaps this can be done with an environment variable, perhaps it requires recompilation of cpp.exe, I don't know.
I am absolutely amazed and grateful that there are such talented and hard-working people as those who contribute to impressive projects like OpenCobol. They make these contributions freely and generously, and I don't think we should undervalue this. If you also want to contribute, then I encourage you to do just that.
Yes, I want to contribute and I'm trying to contribute--I've setup a Git repository devoted to building and hosting an OpenCobol installer for Windows that requires zero yak shaving on the part of the user (thus requiring us to do a little yak shaving ourselves).
Cheers,
Andrew Pennebaker