- Re: mingw errors 1.3.0 1.4.0, (continued)
- Message not available
- Re: mingw errors 1.3.0 1.4.0, Peter Bohning (2018/01/05 16:29:44)
- Re: mingw errors 1.3.0 1.4.0, Dieter Baron (2018/01/05 17:04:42)
- Re: mingw errors 1.3.0 1.4.0, Peter Bohning (2018/01/05 17:20:48)
- Re: mingw errors 1.3.0 1.4.0, Dieter Baron (2018/01/05 18:27:25)
- Re: mingw errors 1.3.0 1.4.0, Peter Bohning (2018/01/08 17:13:22)
You should not disregard my 25 years of experience developing portable Unix software this easily. I know what I’m talking about.
Yes, there are various standards, and for each requirement in them, there is a Unix variant that does not implement it fully.
Again, like I said, why not just have two different files, a handful of defines so that it would work on both mingw and *nix. That's basically all this autoconf/cmake stuff does anyway. So, somehow, you kind of missed my point. I mean I understand, years ago I wanted to use whatever little package things and this and that, as if it was more official. But with cmake particularly, it seems like a useless fad.
Treating all Unix variants as one system is a fundamental misconception. Each variant, and even each version of the same platform, differ in some way.
Now tell me, how do I know which defines to set, which functions are available, if I only have Makefiles? Who sets these defines, so they fit the current platform?
Figuring out how to set these defines is *exactly* what autoconf/cmake are doing, but if you skip them, how do they get set? Statically in the Makefiles? Based on what? Who maintains which defines should be set for which version of which Unix variant?
I’ve seen projects that tried to maintain such a list, and they all failed, because it’s nearly impossible to get right in all cases. It’s much more robust, much easier and much less maintenance work to use a tool that lets the compiler figure it out.
Let me make it abundantly clear: a tool like cmake is *essential* for portability on Unix.
I would also prefer a solution that didn’t require installing third party software, but sadly, I don’t know of any that works well across Unix and Windows. (Makefiles do not fit this requirement: they don’t work well on either platform, let alone on both.)
Until a better tool comes along, we will stick with cmake.
I will probably mess with that some more... and if I get lazy then I will try to find binary packages for cmake, I guess... but I'm sure there will be more problems after that. None of this stuff ever works.
Strangely, I have heard from multiple Windows users successfully building libzip using cmake. To be fair, I’m not sure if any of them used mingw.
So to restate this as clearly as I can: My 25 years of experience developing portable Unix software convinced me that a tool like autoconf/cmake is the only way to maintain portability. Your proposed solution seems to completely miss the messy complexity that is Unix portability.
Made by MHonArc.