search

Obsidian-StudiosInc / ecrire

General purpose graphical Text Editor built on the Enlightenment Foundation Libraries (EFL)
GNU General Public License v3.0
7 stars 1 forks source link

Cannot build on Mac OS X #55

Open Peter2121 opened 4 years ago

Peter2121 commented 4 years ago
Description

Ecrire cannot be built on Mac OS X

Steps to reproduce
  1. Install EFL using Brew
  2. Git clone Ecrire
  3. cmake .in Ecrire dir
System information

Console log:

$ cmake .
-- The C compiler identification is AppleClang 10.0.0.10001145
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Could NOT find eet (missing: EET_LIBRARIES EET_INCLUDE_DIRS)
-- Could NOT find evas (missing: EVAS_LIBRARIES EVAS_INCLUDE_DIRS)
-- Could NOT find edje (missing: EDJE_LIBRARIES EDJE_INCLUDE_DIRS)
-- Could NOT find efreet (missing: EFREET_LIBRARIES EFREET_INCLUDE_DIRS)
-- Could NOT find efreet (missing: EFREET_LIBRARIES EFREET_INCLUDE_DIRS)
-- Could NOT find efreet_mime (missing: EFREET_MIME_LIBRARIES EFREET_MIME_INCLUDE_DIRS)
-- Could NOT find elementary (missing: ELEMENTARY_LIBRARIES ELEMENTARY_INCLUDE_DIRS)
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
EDJE_LIBRARY (ADVANCED)
    linked by target "ecrire" in directory /Users/peter/Programming/ecrire/src/bin
EET_LIBRARY (ADVANCED)
    linked by target "ecrire" in directory /Users/peter/Programming/ecrire/src/bin
EFREET_LIBRARY (ADVANCED)
    linked by target "ecrire" in directory /Users/peter/Programming/ecrire/src/bin
EFREET_MIME_LIBRARY
    linked by target "ecrire" in directory /Users/peter/Programming/ecrire/src/bin
ELEMENTARY_LIBRARY (ADVANCED)
    linked by target "ecrire" in directory /Users/peter/Programming/ecrire/src/bin
EVAS_LIBRARY (ADVANCED)
    linked by target "ecrire" in directory /Users/peter/Programming/ecrire/src/bin

-- Configuring incomplete, errors occurred!
See also "/Users/peter/Programming/ecrire/CMakeFiles/CMakeOutput.log".

pkg-config files for EFL are present in /usr/local/lib/pkgconfig

CMakeOutput.log attached. CMakeOutput.log.txt

wltjr commented 4 years ago

@Peter2121, thank you for testing build under OS X. I do not access to that OS at this time. I would have to use a OS X CI env or hosted VM. However, those issues offhand look to be issues with EFL's cmake support. If you find other EFL stuff using cmake, I believe, you will run into the same errors. I use EFL cmake support in ecrire's cmake build system. The only way I could fix, without replacing or modifying EFL cmake support, would be to switch build systems to like Meson.

It is similar to issues I ran into with another issue, see this comment https://github.com/Obsidian-StudiosInc/ecrire/issues/47#issuecomment-543429864and the following one. I do not expect EFL developers to address issues with the cmake files in EFL. They might since it should affect all EFL usage on OS X using cmake. More than likely, they will suggest to use Meson instead of Cmake. I may switch ecrire to meson someday, time permitting. I may have no choice if EFL developers decide to no longer ship EFL with cmake support. As issues arise with using EFL's cmake support, that may become a motivating factor for EFL developers to stop supporting Cmake entirely, and reduce their maintenance burden.

Peter2121 commented 4 years ago

I'm surprised to discover that an advanced build system like CMake is not able to find libs that have pc files present in a correct place, even without cmake's Find* files. I'm almost sure that a workaround exists ;)

wltjr commented 4 years ago

@Peter2121 it seems cmake is pretty lacking there. EFL has to provide helpers for cmake to find pkg-config pc files. It is one of many reasons why people are switching to meson. I cannot argue against Meson vs CMake when it comes to pkg-config pc file support. I am sure EFL developers would rather not have to create or maintain the cmake helpers if there was a work around.

I looked into options for the other ecrire issue, which was caused by meson changing the order of libraries in pkg-config pc files. That change in pc file library order caused cmake issues, and required further changes to the EFL cmake helpers. It is one area, I am less than impressed with cmake. Given how long it has been around and widely used. CMake developers really need to improve pkg-config support and finding pc files without helpers, or they will likely continue to see more and more switch to meson.

Peter2121 commented 4 years ago

Finally i could build it with the following patch of CMake build file. I don't know how to search the correct version of openssl as we need to mention exactly the same version that was used to build EFL libs, so i manually forced the correct one (see comment in patched file) CMakeLists.diff.txt The first impression is that ecrire is not less stable on Mac OS X than on FreeBSD, I'll continue to test it.

wltjr commented 4 years ago

@Peter2121, very nice work, thank you! I am surprised at the solution, as I spent time looking into cmake options for pkg-config for issue #47. That seemed to be a problem with cmake find files from efl and pc file library order. I wonder if that same issue would have been present using your solution of pkg_search_module. I checked in cmake irc channel a few times about pkg-config support.

Regarding openssl, does that issue only come up when there are different versions available on the system? I was able to build using your patch modifications. Also, it is interesting that it even needs openssl in the library path. I guess something within efl needs that for linking purposes.

It seems like, I can go ahead and apply your patch, as we figure out the openssl situation. It does not presently build on os x, so, not having the openssl issue dialed in is likely moot. The changes will just get things one step closer to building on OS X. Does FreeBSD have the same issue with openssl?

Thanks again!

Peter2121 commented 4 years ago

Regarding openssl, does that issue only come up when there are different versions available on the system? I was able to build using your patch modifications. Also, it is interesting that it even needs openssl in the library path. I guess something within efl needs that for linking purposes.

It is really a difficult situation. Ecrire itself does not need openssl. It is needed by some EFL libs. So, we need openssl in Ecrire link command because we use EFL. And we need exactly the same library that was used during EFL build. And yes, it is a problem when there are several openssl libs present in the system. Right now I have 4 openssl libs on my Mac and 2 openssl libs on my FreeBSD.

On Mac OS X we have an openssl library in base system, we can have several openssl installed by brew, and we can install openssl directly, building it from sources or installing third-party package. And we can use any of these openssl libs, building EFL. So, on Mac OS X we need to check what was the openssl, used by EFL and use this one during the build of Ecrire. As for now, I don't know how to do it using CMake.

On FreeBSD we can have 2 openssl libs - one in base system and one installed from ports/packages. Till https://phab.enlightenment.org/D10789 EFL used the openssl from ports. The actual git version uses openssl from base (and it is really better option). Once again, when we build Ecrire - we need to detect which lib was used for EFL build and put the appropriate option to linker. And once again - I don't know how to do it.

wltjr commented 4 years ago

Interesting, I wonder if this is also an issue on Linux, when there is more than one openssl library available. I also wonder if the situation would be any different with a different build system, say meson. It seems like, we would have the same issue with Meson, needing to know which openssl EFL was built against.

I will research options for openssl version detection time permitting. Thank you for the information and your time spent on this issue.

wltjr commented 4 years ago

@Peter2121, was there a specific reason you increased the version of EFL in your CMake modifications? I am wondering if the changes require that version, or I can commit and push them with say EFL 1.20.7. While we figure out a openssl solution.

I am stuck on EFL 1.20.7 for CI usage, as the person packaging EFL for ubuntu in ppa:niko2040/e19 stopped doing updates and went MIA sometime back. I started work on making a new one in ppa:wltjr/epkgs, but I ran into problem with older versions of dependencies. Now, that Travis CI has update to newer versions of Ubuntu, I can resume that effort and hopefully produce an updated EFL package for Ubuntu.

I am also working on a Docker EFL image for app development/testing. That is some what good to go, just much bigger than I want. I need to work with that container locally and produce an updated version that is hopefully much smaller.

Peter2121 commented 4 years ago

was there a specific reason you increased the version of EFL in your CMake modifications I've just put the current version installed by brew. I don't think it is really important. BTW, 1.20.7 is really old, I don't think that any tests with such version could be important.

wltjr commented 4 years ago

I agree, 1.20.7 is old for testing, but that is what I am stuck with for CI, for now. Also, any of the code analysis tools also want it built, like Coverity and Sonar.

I will go ahead and commit the changes, less the comment and version increase. If it fails for some reason in CI, I will revert till I can update the EFL package in Ubuntu.