New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GElektra: add basic devhelp generation #769

Open
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@raetiacorvus
Contributor

raetiacorvus commented Jun 2, 2016

This ads devhelp generation if glib bindings are enabled and gtk-doc is found.

Currently this only contains the object hierarchy and all methods.

ref #766

@@ -33,7 +33,7 @@ else()
target_compile_options (${GELEKTRA_LIBRARY} PUBLIC ${GOBJECT_CFLAGS_OTHER})
target_link_libraries (${GELEKTRA_LIBRARY} PUBLIC elektra-core elektra-kdb)
target_link_libraries (${GELEKTRA_LIBRARY} PUBLIC ${GOBJECT_LDFLAGS})
target_link_libraries (${GELEKTRA_LIBRARY} PUBLIC ${GOBJECT_LIBRARIES})

This comment has been minimized.

@raetiacorvus

raetiacorvus Jun 2, 2016

Contributor

I hope this change does not break anything, but gtk doc did put the wrong linking flags with ${GOBJECT_LDFLAGS}

This comment has been minimized.

@markus2330

markus2330 Jun 3, 2016

Contributor

@manuelm what do you think here? Is this a bug?

A separate PR (or at least commit) for this might be useful (if this change should be done)

This comment has been minimized.

@manuelm

manuelm Jun 3, 2016

Contributor

GOBJECT_LIBRARIES will be missing important linker flags, so linking might break. I've spent quite some time (read: hours) investigating into the different variables pkg-config is returning. _LIBRARIES will be insufficient.

This comment has been minimized.

@markus2330

markus2330 Jun 3, 2016

Contributor

Is there some docu about your findings? Is GOBJECT_LIBRARIES a subset of GOBJECT_LDFLAGS? Any explanation why "linking against ldflags" makes sense?

This comment has been minimized.

@manuelm

manuelm Jun 3, 2016

Contributor

No. I read the docs + looked at various .pc files on different linux distributions.
Yes, libraries is a subset of ldflags. And we're not "linking against ldflags". target_link_libraries is just misleading.

This comment has been minimized.

@raetiacorvus

raetiacorvus Jun 3, 2016

Contributor

Thank you for the tipp.
In the long run we probably should solve this with a proper findGObject.cmake

This comment has been minimized.

@raetiacorvus

raetiacorvus Jun 3, 2016

Contributor

Ah no it does not solve the problem.
Lets put this on hold till we have a proper findGObject.cmake

This comment has been minimized.

@markus2330

markus2330 Jun 3, 2016

Contributor

Why do you think that the findGObject.cmake is not proper? Did you report a bug somewhere?

This comment has been minimized.

@raetiacorvus

raetiacorvus Jun 3, 2016

Contributor

We dont have yet a findGObject.cmake only a FindGObjectIntrospection.cmake forgi.
The Elektra GLib bindings currently use pkg-config module
using
${GOBJECT_LDFLAGS} should be equal to pkg-config gobject-2.0 --libs

I really do not understand yet why this should pull in -lpthread or -fPIE, but i am no expert of cmake yet.

This comment has been minimized.

@raetiacorvus

raetiacorvus Jun 3, 2016

Contributor

you only get -pthread if you use the STATIC prefix e.g. ${GOBJECT_STATIC_LDFLAGS}

install (DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/gelektra/html/
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/gtk-doc/html/gelektra
)
endif (GTKDOC_FOUND)

This comment has been minimized.

@markus2330

markus2330 Jun 3, 2016

Contributor

Do you think silent not-building of doc is a good idea? Add some warning if GtkDoc not found?

This comment has been minimized.

@raetiacorvus

raetiacorvus Jun 3, 2016

Contributor

I actually added something but must have gotten lost in some copy paste

@markus2330

This comment has been minimized.

Contributor

markus2330 commented Jun 3, 2016

Thank you, looks really nice. The ${GOBJECT_LIBRARIES} issue has to be investigated though. Mac OS X build fails:

[ 30%] Linking C shared library ../../../lib/libgelektra-4.0.dylib

ld: library not found for -lintl

clang: error: linker command failed with exit code 1 (use -v to see invocation)
@raetiacorvus

This comment has been minimized.

Contributor

raetiacorvus commented Jun 3, 2016

Yes i noticed, i think we have to get a proper findGobject.cmake to solve this. It has to do how homebrew handles gettext installation.

@markus2330

This comment has been minimized.

Contributor

markus2330 commented Jul 13, 2016

@manuelm can you give some help here how @sirblackheart can fix it?

@manuelm

This comment has been minimized.

Contributor

manuelm commented Jul 15, 2016

I'm sorry but I don't have access to any OS X machine. Maybe the best is to leave gi bindings broken on OSX unless someone else fixes the cmake files.

Or we strip of -lintl on OS X. On FreeBSD 10 and above (afair) gettext is embedded into glibs. Maybe it's the same on OS X.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment