+ add CMake support

[0xeb]

Added CMake support with ida-cmake.

This is the preliminary CMake support.

The building instructions need to be merged / updated after PR #1 is checked in and merged.

[Naville]

Probably should try to FindZ3 first instead of always relying on user.

Ref: https://github.com/llvm/llvm-project/blob/main/llvm/cmake/modules/FindZ3.cmake

[Naville]

Also, this doesn't work with z3.a

[0xeb]

I want to keep it simple and self-contained. This mimics the way the Makefile that is with this project. The current plugin assumes the compiled z3 are downloaded before hand.

[Naville]

In your message string:

 '<Z3_DIR>/lib/libz3${CMAKE_STATIC_LIBRARY_SUFFIX}'

Which assumes lib/libz3.a

But in your detection code:

${Z3_DIR}/bin/libz3${CMAKE_STATIC_LIBRARY_SUFFIX}

Which expects bin/libz3.a

[0xeb]

Correct, I should have used ${CMAKE_SHARED_LIBRARY_SUFFIX} for non-Windows. Let me test on Linux and review my PR. Thanks.

[Naville]

HexRays SDK is not shipped with IDA SDK, so probably in your ida-cmake repo another option should be added to allow specifying HexRays SDK path?

[0xeb]

No, not needed. By convention, users are expected to copy the header files to the \include . Again, this is to conform with IDA's build system (its own make files).

[Naville]

Correct, I should have used ${CMAKE_SHARED_LIBRARY_SUFFIX} for non-Windows. Let me test on Linux and review my PR. Thanks.

The actual path used for detection is not the same as the one used in the error message, that leads to confusions I think?

[0xeb]

Thanks, I will revise and test on Linux too.

Also, for your other comments about finding Z3, please check the 'z3' subfolder.

With ida-cmake, you are supposed to be able to build with both "make" (as it comes with a given plugin) and with CMake. Hence, not using additional CMake scripts to find z3, etc.

[0xeb]

Also, I discovered that ida-cmake , as it is now, does not work with SDK 8.2sp1. I will update ida-cmake shortly, then that will fix the suffix situation too.

There seems to be no direct way in CMake to yield *.so on Linux, *.dylib on macOS and *.lib on Windows unfortunately. If you know, any ideas?

[Naville]

I dont quite understand? add_library(SHARED) gets you dll on Windows, dylib on macOS and so on Linux by default?

Which you can override with CMAKE_SHARED_LIBRARY_SUFFIX

[0xeb]

I dont quite understand? add_library(SHARED) gets you dll on Windows, dylib on macOS and so on Linux by default?

Which you can override with CMAKE_SHARED_LIBRARY_SUFFIX

Sure, but I am not asking how to create a target (with add_library). I want to add a target_link_libraries() and specify the proper extensions.

[0xeb]

I dont quite understand? add_library(SHARED) gets you dll on Windows, dylib on macOS and so on Linux by default? Which you can override with CMAKE_SHARED_LIBRARY_SUFFIX

Sure, but I am not asking how to create a target (with add_library). I want to add a target_link_libraries() and specify the proper extensions.

For example, if I don't specify the full extension for the target_link_libraries(), then on Windows, CMake will use the .lib extension for static libraries but on Linux and macOS, CMake will use the .a extension for static libraries and the .so or .dylib extension for shared libraries, respectively. The problem is we want to use the "SHARED" but then on Windows, CMake will use ".dll".

Now, hopefully my question makes sense?

[0xeb]

Let me rephrase, we do generate a library target to produce plugins. We want to link with ".lib", ".so" and ".dylib" (on Windows, Linux and macOS). What's the proper suffix macro?

[0xeb]

Let me rephrase, we do generate a library target to produce plugins. We want to link with ".lib", ".so" and ".dylib" (on Windows, Linux and macOS). What's the proper suffix macro?

Windows / SHARED: .dll Windows / STATIC: .lib

*nix / SHARED: .so *nix / STATIC: .a

What I want is a proper prefix that yields: .lib, .so and .dylib. I can't seem to find that such macro. I mean we can compute the proper suffix based on the platform, etc.

[Naville]

I'm from macOS background so I'll try to understand the problem in macOS environment.

Basically, say there is libz3.a and libz3.dylib in a folder, and you want to prefer libz3.a over libz3.dylib?

Don't think you can do that other than overriding CMAKE_FIND_LIBRARY_SUFFIXES and CMAKE_FIND_LIBRARY_PREFIXES

[0xeb]

I'm from macOS background so I'll try to understand the problem in macOS environment.

Basically, say there is libz3.a and libz3.dylib in a folder, and you want to prefer libz3.a over libz3.dylib?

Don't think you can do that other than overriding CMAKE_FIND_LIBRARY_SUFFIXES and CMAKE_FIND_LIBRARY_PREFIXES

yes, we want the dylib for sure. that's what the pre-built packages ship with. That's what IDA SDK uses too (the extensions).

When we override those suffixes, we have to add some logic per platform, correct?

Something like:

if(APPLE)
  set(MY_LIBRARY_SUFFIX ".dylib")
elseif(UNIX)
  set(MY_LIBRARY_SUFFIX ".so")
elseif(WIN32)
  set(MY_LIBRARY_SUFFIX ".lib")
endif()

[Naville]

Or you can filter on the default values. Like:

list(REMOVE CMAKE_FIND_LIBRARY_SUFFIXES ".dll")

or something like that

[0xeb]

Thank you @Naville for your feedback.

I fixed the issues, it should now build on macOS/Linux too and make the error message consistent.

It requires the latest ida-cmake update though.

[0xeb]

I might add support to the same environment variables that the existing Makefile supports as well. Like this, one can build with IDA's make or just CMake (this keeps compatibility between those two build systems).

[Naville]

Come to think about, we really should ask HexRays to implement a proper cmake-based build system ffs

[0xeb]

Good luck with that ;)

[Naville]

Yeah, don't think that's going to happen lol

[0xeb]

Not any time soon. Building on Windows is painful with the existing make system. That’s why I put together a layman CMake alternative (I am no CMake expert). I would love your feedback if we can improve Ida-CMake in my repo though.

[aundro]

We will be officially shipping gooMBA with IDA 8.3 (and going forward), which means that a CMake-based build system will not really work for us - unless, as mentioned, we move our entire build system to CMake, which won't happen any time soon (in any case.)

[Naville]

We will be officially shipping gooMBA with IDA 8.3 (and going forward)

Thank you, great to hear!

move our entire build system to CMake, which won't happen any time soon

Eww and sigh, but technical burdens I guess...

[aundro]

[…]

move our entire build system to CMake, which won't happen any time soon

Eww and sigh, but technical burdens I guess...

Indeed. It would only be added maintenance for us, and would not really fit since the rest of the build is not CMake-based.

[0xeb]

@aundro , I spent 4 hours making this work to give convenience to users, especially on Windows. Time wasted :(

All this change is about is a single file: CMakeLists.txt

Let me ask you this: are you going to go closed source when you release with 8.3? If so, why not simply delete that file from your repo (since anyway you're not going to maintain it).

If not, why not give the convenience to users? Very few users use VS2019 on Windows, let alone Cygwin just to have make.exe, etc.

[0xeb]

We will be officially shipping gooMBA with IDA 8.3 (and going forward), which means that a CMake-based build system will not really work for us - unless, as mentioned, we move our entire build system to CMake, which won't happen any time soon (in any case.)

Ok, this PR was not intended for IDA's internal repo, but for the public who prefer to use modern build scripts such as CMake.

In all cases, for posterity reasons, you can find the CMake build script here: https://github.com/0xeb/ida-cmake/blob/master/plugins/goomba/BUILDING.md

[Naville]

Time wasted :(

Definitely not wasted, here is a user that's been saved by your work :)