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

can't build #20

Closed NuLogicSystems closed 6 years ago

NuLogicSystems commented 6 years ago

I'm getting: 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 /build/ecrire-git/src/ecrire/src/bin ELEMENTARY_LIBRARY (ADVANCED) linked by target "ecrire" in directory /build/ecrire-git/src/ecrire/src/bin

-- Configuring incomplete, errors occurred! See also "/build/ecrire-git/src/ecrire/CMakeFiles/CMakeOutput.log".

wltjr commented 6 years ago

Can you attach that log? That is pretty strange it fails. I have not had any build failures on Gentoo, nor on Travis using Ubuntu. Unless something in EFL changed. Would be odd if no longer providing edje or elementary libraries.

NuLogicSystems commented 6 years ago

Ok maybe a problem in your CmakeLists.txt: -- Could NOT find edje (missing: EDJE_LIBRARIES EDJE_INCLUDE_DIRS) -- Found efreet: /usr/lib/libefreet.so -- Found efreet_mime: /usr/lib/libefreet_mime.so -- Could NOT find elementary (missing: ELEMENTARY_LIBRARIES ELEMENTARY_INCLUDE_DIRS)

wltjr commented 6 years ago

No something seems to have changed with EFL or something.

# Version only needed in first
find_package(Eo ${EFL_VERSION} REQUIRED)
find_package(Eina ${EFL_VERSION} REQUIRED)
find_package(Eet ${EFL_VERSION} REQUIRED)
find_package(Evas ${EFL_VERSION} REQUIRED)
find_package(Ecore ${EFL_VERSION} REQUIRED)
find_package(Ecore COMPONENTS INPUT)
find_package(Edje ${EFL_VERSION} REQUIRED)
find_package(Efreet ${EFL_VERSION} REQUIRED)
find_package(Efreet COMPONENTS mime)
find_package(Elementary ${EFL_VERSION} REQUIRED)

Could be something off with pkgconfig. Do you not have a /usr/lib64/libedje.so and /usr/lib64/libelementary.so?

NuLogicSystems commented 6 years ago

I'm using efl 1.20.5. Let me check my build of efl.

wltjr commented 6 years ago

I am as well, and same on Travis. Thus something must be off in your environment or something. Those have always been there going back to the original repo. Nothing has changed, and it definitely needs to link against those libraries.

Look for edje.so and elementary.so. Something is not able to find them. What version of cmake? Maybe something else causing it to not find those libraries. Pretty sure pkg-config is used as well here.

$ pkg-config --libs elementary
-lelementary -lefl -leina -lpthread -leet -levas -lecore -lecore_evas -lecore_file -lecore_input -ledje -leo -lethumb_client -lemotion -lecore_imf -lecore_con -leldbus -lefreet -lefreet_mime -lefreet_trash -leio -lpthread -lm -ldl -lrt

$ pkg-config --libs edje
-ledje
NuLogicSystems commented 6 years ago

Here is what I got..

pkg-config --libs elementary
-lelementary -lefl -leina -lpthread -leet -levas -lecore -lecore_evas -lecore_file -lecore_input -ledje -leo -lethumb_client -lemotion -lecore_imf -lecore_con -leldbus -lefreet -lefreet_mime -lefreet_trash -leio -lpthread -lm -ldl -lrt

pkg-config --libs edje
-ledje
wltjr commented 6 years ago

Travis hides that section but you can see it in Shippable under Build CI.

-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1") 
-- Found eo: /usr/lib/x86_64-linux-gnu/libeo.so  
-- Found eina: /usr/lib/x86_64-linux-gnu/libeina.so  
-- Found eet: /usr/lib/x86_64-linux-gnu/libeet.so  
-- Found evas: /usr/lib/x86_64-linux-gnu/libevas.so  
-- Found ecore: /usr/lib/x86_64-linux-gnu/libecore.so  
-- Found ecore_input: /usr/lib/x86_64-linux-gnu/libecore_input.so  
-- Found edje: /usr/lib/x86_64-linux-gnu/libedje.so  
-- Found efreet: /usr/lib/x86_64-linux-gnu/libefreet.so  
-- Found efreet_mime: /usr/lib/x86_64-linux-gnu/libefreet_mime.so  
-- Found elementary: /usr/lib/x86_64-linux-gnu/libelementary.so  
wltjr commented 6 years ago

Seems the other libraries in your case are in /usr/lib per the above

-- Found efreet: /usr/lib/libefreet.so
-- Found efreet_mime: /usr/lib/libefreet_mime.so

You need to see if you have a

/usr/lib/libedje.so
/usr/lib/libelementary.so

Seems yours is not there. You need to find where libedje.so and libelementary.so are on your system.

NuLogicSystems commented 6 years ago

I just checked my EFL package and they are indeed there. I build in a clean chroot so this is strange..

NuLogicSystems commented 6 years ago

Frack it pulled in the arch package 1.20.3, not mine. Let me go fix this crap again.

wltjr commented 6 years ago

Yes indeed, something is causing cmake to not find those libraries. Not sure what I can change as that stuff in cmake is pretty straight forward. Why its called find_package. So your saying you have a /usr/lib/libedje.so and /usr/lib/libelementary.so and cmake is failing to find them? That is pretty strange. Not sure how I can replicate to fix.

wltjr commented 6 years ago

Ah no worries, but makes senses that something in env is off. Must have something off in that version of EFL.

NuLogicSystems commented 6 years ago

OK that's better, it's not you it's arch.. My EFL package works right. ;) However, you did remove ChangeLog and NEWS, so I did need to fix that in my PKGBUILD..

wltjr commented 6 years ago

Yes, autotools needs those, one was empty and the other never really used. Stop using autotools, use ninja instead :) I think autogen.sh or some autotools things can re-generate those. Maybe even a missing cmake flag not sure.

Best to use ninja its faster

cmake -G Ninja
ninja package

Change out package for what ever target, compile etc. You will see the speed of cmake + ninja is basically the same as meson + ninja. I like aspects of cmake better than meson, like ability to generate deb and rpm without a spec file, etc. Meson can generate a spec file but I can create one myself. its the actual rpm/deb I like that cmake makes for me :)

NuLogicSystems commented 6 years ago

I'll try that next time. ;)

wltjr commented 6 years ago

Yeah I may need to suggest people avoid auto tools or create those files, or autogen.sh. Which is common for autotools, but not so much for cmake. In fact running that maybe odd. I have to see when the error occurs, during cmake or make after. I guess I could add back. NEWS i believe was empty. At some point will do a ChangeLog from git commits I think. Mostly spending time on the package itself vs other stuff like that. I was adding translations, have most those done, at least for those that exist. Short of the 2 byte ones, copy and paste was doing some funny stuff.

NuLogicSystems commented 6 years ago

The issue wasn't building, it was in my packaging of these files:

# install text files
  install -d "$pkgdir/usr/share/doc/$_pkgname/"
  install -m644 -t "$pkgdir/usr/share/doc/$_pkgname/" AUTHORS ChangeLog NEWS

I change this to: install -D -m644 COPYING $pkgdir/usr/share/licenses/$pkgname/COPYING

I wouldn't waste too much time on this. ;)

wltjr commented 6 years ago

Ok that's good. I know regular auto tools build will complain and fail. There is an option to have it auto generate missing stuff. I thought cmake makefile generation took care of that. If it comes up again I can restore them. Prefer the least files in root directory as possible.