Is that possible to remove GLib

[zhoub]

Hi !

I'd like to ask is that possible to remove the dependency of glib. Thanks !

[Jackey-Huo]

follow you, I need to cross compile lcm c++ lib, and glib make me a huge amount of trouble.

[ghost]

It looks like glib is used for a few items:

• Regular expression matches on the channel name
• Helps with the logger example
• Drives event loop for some applications
• LCM unit tests

Addressing this issue is no small task:

• The LCM logger would need to be decoupled into its own independent project (that isn't required to build LCM proper).
• The event loop constraints can also be moved out into a demonstration project.
• The LCM tests for using regular expressions in channel names must be removed from the project.
• Source files would need to be revamped into a sane hierarchy; nearly every source file includes <glib.h>, but every C source file need only include a single corresponding .h file, IMO, and the .h files only include the libraries that specifically express prototypes used by the C source files.

Another issue is that a lot of g_ functions are called throughout the code base, which is still more coupling to glib. For example, is_handler_subscriber in lcm/lcm.c calls g_regex_match to compare the subscriber name. Architecturally, having a pluggable name-matching algorithm would be necessary to decouple glib from LCM while offering a path for backwards-compatibility. The default would use a simple case-sensitive string comparison; a separate demo project could show regex matching.

As far as I can tell, LCM doesn't need to use glib for its core pub/sub functionality. There may be additional changes required. Here's the list of files I modified before I stopped, to give you some idea of how tangled glib is with the system:

	modified:   .travis.yml
	modified:   CMakeLists.txt
	modified:   cmake/FindGLib2.cmake
	modified:   examples/c/Makefile
	deleted:    examples/c/listener-glib.c
	modified:   lcm-cmake/cpack.cmake
	modified:   lcm-cmake/lcmConfig.cmake.in
	deleted:    lcm-logger/CMakeLists.txt
	deleted:    lcm-logger/glib_util.c
	deleted:    lcm-logger/glib_util.h
	deleted:    lcm-logger/lcm-logger.1
	deleted:    lcm-logger/lcm-logplayer.1
	deleted:    lcm-logger/lcm_logger.c
	deleted:    lcm-logger/lcm_logplayer.c
	modified:   lcm-lua/rock/lcm-1.4.0-0.rockspec
	modified:   lcm-pkgconfig/lcm.pc.in
	modified:   lcm-python/pylcm.c
	modified:   lcm-python/setup.py
	modified:   lcm/CMakeLists.txt
	modified:   lcm/lcm-cpp.hpp
	modified:   lcm/lcm.c
	modified:   lcm/lcm.h
	modified:   lcm/lcm_internal.h
	modified:   lcm/lcm_mpudpm.c
	modified:   lcm/lcm_udpm.c
	modified:   lcm/udpm_util.h
	modified:   lcmgen/CMakeLists.txt
	modified:   lcmgen/emit_lua.c
	modified:   lcmgen/emit_python.c
	modified:   lcmgen/getopt.h
	modified:   lcmgen/lcmgen.h
	deleted:    liblcm-test/CMakeLists.txt
	deleted:    liblcm-test/buftest-receiver.c
	deleted:    liblcm-test/buftest-sender.c
	deleted:    liblcm-test/lcm-example.1
	deleted:    liblcm-test/lcm-example.c
	deleted:    liblcm-test/lcm-logfilter.c
	deleted:    liblcm-test/lcm-sink.1
	deleted:    liblcm-test/lcm-sink.c
	deleted:    liblcm-test/lcm-source.1
	deleted:    liblcm-test/lcm-source.c
	deleted:    liblcm-test/lcm-tester.1
	deleted:    liblcm-test/lcm-tester.c
	modified:   m4macros/lcm.m4
	modified:   test/gtest/include/gtest/internal/gtest-port.h
	modified:   test/gtest/src/gtest.cc

[judfs]

Would porting to C++11 (or newer) and just marking everything extern c be an option? Gets you threads and regex.

With a bit of googling I didn't find anything claiming to be the way to do cross platform threading in C. Even C11 threads are an optional feature.

(Would dropping glib make building for windows simpler / wouldn't need mingw?)

[tprk77]

@DaveJarvis GLib is also used for maps (GHashTable), so it is used in core functionality. Take a look at lcm.c if you're curious.

@judfs I think it's possible, it's more a question of if the benefit is worth the potential risk of rewriting core functionality. Additionally, one of the original selling points was that LCM did not have any strong requirement on compiler version, so you could (probably) get it to compile with archaic compilers*, i.e., C89 on weird architectures. I'm not sure if that's still a desired feature; that would be a question for the current maintainers.

(* Assuming you could get GLib to compile.)

[ghost]

For anyone else coming into this thread, D-Bus may be a viable alternative.