List Archive

Thread

Thread Index

Message

From: "Peter Bohning" <peter.bohning%gmx.com@localhost>
To: "Dieter Baron" <dillo%nih.at@localhost>, libzip-discuss%nih.at@localhost
Subject: Re: mingw errors 1.3.0 1.4.0
Date: Fri, 5 Jan 2018 17:39:46 +0100

On 04.01.2018, at 19:22 , Peter Bohning <peter.bohning%gmx.com@localhost> wrote:
 
Sorry.  Didn't mean to sound hostile, I'm mostly just sarcastic.  I've just been doing this stuff for so many years and nothing ever changes.  I know most people use autoconf, I've always kind of wondered why.  It goes through and checks for all these types and sizes and which functions are supported... I don't really understand why POSIX compliance isn't... I don't know, more complete and supported by the government or something... most of the setups and operating systems are basically the same, I don't get why this is all such a mess.
 
>>Because there are may different Unix variants, all supporting a different set of functions/types. The most reliable way to find out which are supported on the platform you are trying to compile on is to test using the compiler. And that’s exactly what autoconf and cmake do, and that’s why most modern open source projects use one of them.
 
>>autoconf has the advantage that it only uses tools that come preinstalled on almost all Unix variants. cmake has the advantage that it also works on Windows.
 
No, you missed my point.  There should be, and are to some degree, standards such that the implementation differences among Unix variants should be irrelevant to development.
 
>> And that’s why libzip is using cmake and why simple Makefiles will not suffice.
 
Woah, kind of jumped a bit there.  Just because there might be design problems such that source configuration tools could be useful, does not mean that libzip needs them.
 
>>Sure, I could make compiling it on your specific mingw setup easy, by breaking it on most Unix versions. Somehow, that’s not a trade-off I’m willing to make. 
 
>>There are binary packages for cmake for Windows. Have you tried if those work for you? If not, have you asked on cmake mailing lists for help?
 
>>yours,
>>dillo
 
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.
 
I'd prefer not to use cmake.  If I'm forced to use it, I can't see why I can't compile it from source.
 
Recently, I had a few minutes and I found libzip 1.3.2 on some website. 
 
I had to add #include "Wincrypt.h" to zip_random_win32.c, and then I had to comment out a mingw line in stdio.h about some __mingw_redirect_stdio__ snprintf thing... and then it almost compilies but I get:
 
mv -f .deps/ziptool.Tpo .deps/ziptool.Po
/bin/sh ../libtool  --tag=CC   --mode=link gcc  -g -O2 -I/usr/local/include  -L/usr/local/lib -o ziptool.exe source_hole.o ziptool.o ../lib/libzip.la -lz
libtool: link: gcc -g -O2 -I/usr/local/include -o .libs/ziptool.exe source_hole.o ziptool.o  -L/usr/local/lib ../lib/.libs/libzip.a -lz
source_hole.o: In function `source_hole_cb':
C:\MinGW\msys\1.0\home\peterius\libzip-1.3.2\src/source_hole.c:527: undefined reference to `_imp__zip_error_to_data'
source_hole.o: In function `hole_free':
C:\MinGW\msys\1.0\home\peterius\libzip-1.3.2\src/source_hole.c:468: undefined reference to `_imp__zip_error_fini'
source_hole.o: In function `buffer_seek':
C:\MinGW\msys\1.0\home\peterius\libzip-1.3.2\src/source_hole.c:288: undefined reference to `_imp__zip_source_seek_compute_offset'
source_hole.o: In function `source_hole_cb':
C:\MinGW\msys\1.0\home\peterius\libzip-1.3.2\src/source_hole.c:583: undefined reference to `_imp__zip_source_make_command_bitmap'
 
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.
Sent: Thursday, January 04, 2018 at 2:19 PM
From: "Dieter Baron" <dillo%nih.at@localhost>
To: "Peter Bohning" <peter.bohning%gmx.com@localhost>
Cc: libzip-discuss%nih.at@localhost
Subject: Re: mingw errors 1.3.0 1.4.0
 
 
On 04.01.2018, at 19:22 , Peter Bohning <peter.bohning%gmx.com@localhost> wrote:
 
Sorry.  Didn't mean to sound hostile, I'm mostly just sarcastic.  I've just been doing this stuff for so many years and nothing ever changes.  I know most people use autoconf, I've always kind of wondered why.  It goes through and checks for all these types and sizes and which functions are supported... I don't really understand why POSIX compliance isn't... I don't know, more complete and supported by the government or something... most of the setups and operating systems are basically the same, I don't get why this is all such a mess.
 
Because there are may different Unix variants, all supporting a different set of functions/types. The most reliable way to find out which are supported on the platform you are trying to compile on is to test using the compiler. And that’s exactly what autoconf and cmake do, and that’s why most modern open source projects use one of them.
 
autoconf has the advantage that it only uses tools that come preinstalled on almost all Unix variants. cmake has the advantage that it also works on Windows.
 
 
 
And that’s why libzip is using cmake and why simple Makefiles will not suffice.
 
 
But here... there's like 10 different types here, right?  Wouldn't it be easier to put them in separate files, and have a windows and a *nix compile?  I mean that's basically all there is now: windows and *nix... I'm not even saying anything about libzip here, this whole thing just seems crazy to me... this is 2018... are you telling me I have to compile this whole other cmake thing, which also won't compile on my mingw, just to define like ten different types for libzip?  And that's the same problem with autoconf... it's like you sit there waiting for it to run through configure and all these types, and the actual program uses a handful of them…
 
Sure, I could make compiling it on your specific mingw setup easy, by breaking it on most Unix versions. Somehow, that’s not a trade-off I’m willing to make. 
 
There are binary packages for cmake for Windows. Have you tried if those work for you? If not, have you asked on cmake mailing lists for help?
 
yours,
dillo
 
 
I would like the application I wrote to be easy for people to compile and install... if I didn't, I would write my own makefile for libzip, quite frankly, and just define the types as necessary.
 
I don't know what to do and I don't really have time to deal with it.  cmake won't compile.  I guess it doesn't matter.  I'm not getting paid for my application, why go through this hassle.  Yeah I guess maybe I'll write my own makefile for libzip, it can't be more trouble than getting cmake to compile.
Sent: Thursday, January 04, 2018 at 8:06 AM
From: "Dieter Baron" <dillo%nih.at@localhost>
To: "Peter Bohning" <peter.bohning%gmx.com@localhost>
Cc: "libzip mailing list" <libzip-discuss%nih.at@localhost>
Subject: Re: mingw errors 1.3.0 1.4.0
hi,
 
On 04.01.2018, at 03:04 , Peter Bohning <peter.bohning%gmx.com@localhost> wrote:
 
And libzip is not that complicated.  What does it need cmake for anyway?  Just for fun?  Just to stay trendy?
 
We need to check which functions and types the platform libzip is compiled on supports. There are two common tools to do this: autoconf/automake and cmake. Since we want to support Windows and autoconf needs sh(1) (which is not available on Windows), cmake is our only practical option.
 
BTW, I would really appreciate it if you could tone it down a little; you come across as rather aggressive.
 
yours,
dillo
 

Made by MHonArc.