libplist

libplist copied to clipboard

I was wondering whether you'd consider using CMake as the build system for libplist and other libimobiledevice projects?

One of the advantages of CMake is that it's a bit easier to use other toolchains on non-Unix-like systems (like msvc on Windows).

My vote goes to meson for the faster compiles :).

I have an incomplete WIP branch that does this. I doubt I'll finish it though.

I think we need an adjustment so that it can work on MSVC or other compilers? For example:

#if defined(_MSC_VER) __pragma(pack(push, 1)) typedef struct{ #else typedef struct attribute((packed)) { #endif

---

#if defined(_MSC_VER) __pragma(pack(pop)) #endif

#if defined(_MSC_VER) #define get_unaligned(ptr) *** #else #define get_unaligned(ptr) *** #endif

#if defined(_MSC_VER) #define UINT_TO_HOST(x, n) *** #else #define UINT_TO_HOST(x, n) *** #endif

@nikias Now it is used on windows. At present, it is compiled by MinGW. It is difficult to debug libimobiledevice series using MSVC compiler

I was wondering whether you'd consider using CMake as the build system for libplist and other libimobiledevice projects?

One of the advantages of CMake is that it's a bit easier to use other toolchains on non-Unix-like systems (like msvc on Windows).

Maybe we can help the author complete the cmake compilation chain? If the author permits.

https://github.com/libimobiledevice-cmake/libplist

I have a basic version of MSVC cmake, and other platforms have not been built yet

Awesome, https://github.com/libimobiledevice-win32/ has a bunch of patches for msvc if you're interested in it :-)

Thank you for the link. I'll take a good look.

https://github.com/libimobiledevice-cmake/libplist

I have a basic version of MSVC cmake, and other platforms have not been built yet

I also wrote a draft https://github.com/OznOg/libplist/tree/add_cmake but I see that your version is sligltly more complex than mine (apparently because of MSVC stuff); I don't have a windows machine to test mine on windows (yours does not build on linux); maybe we can share some parts?

@OznOg I do cross platform work. But I mainly debug on windows. Therefore, I made the cmake version to check the problem. If you need any information on windows, I'd be happy to provide it.

@OznOg One thing is, if you make cmake version, you should be compatible with pkgconf. Also, you need to build Autoconf related files. Because the author uses some macros to judge the code compilation and relies on config.h .

@OznOg One thing is, if you make cmake version, you should be compatible with pkgconf.

That was one of my questions :); BTW, is ising pkg-config mandatory if I provide a PlistConfig.cmake file (detection for cmake)?

Also, you need to build Autoconf related files. Because the author uses some macros to judge the code compilation and relies on config.h .

I did not understand this one: if moving to cmake, no need for autoconf stuff anymore, isn't it?

@OznOg If you do not provide pkgconf, others can only use cmake. Moreover, there are some dependencies in the code on config.h . Therefore, platform difference check is required. for example: https://github.com/libimobiledevice/libplist/blob/ebf2fdb938c755026668c8418da290e6870c1987/src/time64_limits.h#L32 https://github.com/libimobiledevice/libplist/blob/1f6cb66777c0e33ce25dff5cd98f46102451f927/src/xplist.c#L28

meh. meson defaults to pkgconf.

@OznOg If you do not provide pkgconf, others can only use cmake. Moreover, there are some dependencies in the code on config.h . Therefore, platform difference check is required. for example:

https://github.com/libimobiledevice/libplist/blob/ebf2fdb938c755026668c8418da290e6870c1987/src/time64_limits.h#L32

https://github.com/libimobiledevice/libplist/blob/1f6cb66777c0e33ce25dff5cd98f46102451f927/src/xplist.c#L28

fair enough, I'll have a look at this

The author mainly uses Autoconf So I'm not sure if he will use more conditional compilation in the future. Check as many configurations as possible, and the check can also be copied and used directly in other projects.

But is there a will to move from autotools to cmake or not? I really think that having 2 build chains to maintain is a pain, so if the project wants to keep autotools eventually, I think that writing cmake files (or meson) is purely a bad idea. Let there be clear about it, better give it up now than when a lot of work is done already :)

I agree with this statement. It mainly depends on what the @nikias thinks. Personally, I think cmake or meson is much better than Autotools. Many large projects now support cmake, which is really convenient and easy to debug (especially on MSVC). Moreover, the cmake version I built is only used to check the memory value when there is a problem.

@nikias Are there plans to support CMake or other build systems when? Looking forward to the CMake build system.