From: Andrej N. G. <an...@re...> - 2012-08-09 11:21:24
|
Hello! I want to change how libfm header files are installed a bit. How them are installed right now makes usage of pkg-config mandatory. Mostly due to installing them into /usr/include/libfm/libfm. I know, that is because libfm follows exclusive Gnome (Glib/Gtk) way strictly but I highly doubt the Gnome ways (as opposed to all other software) are the best ones in the world. So I want to make usage of pkg-config optional (i.e. only for autotools or similar systems) instead of being mandatory. Main reasons for such move are: 1. I don't like the way Gnome people go and I don't like the way they think everyone else will follow their exclusive path. 2. I like the idea to preserve a room to allow different versions of the libfm coexist together when it matures. 3. I would like to let developers use libfm in more simple ways without pkg-config but just adding '-lfm' to linker arguments. 4. The debian bug tracker have a bug about libfm headers already. So I would like to make it such way that pkgconfig/autotools aren't mandatory to use libfm anymore but preserve versioning at the same time. And make it not by Gnome way but the way all other products do it (for example: Linux kernel; Tcl; Libpng; Python; etc.) - i.e. install path have the version but actual path is symlink to versioned path and user can easily either switch the symlink or set versioned path in #include statement ("libfm1.1/fm.h" for example) to use another version of the library. I want to make it both for the headers path and for pkgconfig descriptor. So anyone can compile in libfm with just gcc -I/usr/include/glib-2.0 -lfm -o fm-test fm-test.c without all the hell of pkgconfig/autotools. Unfortunately, it still will require Gnome include though due to their ugly way to make things. ;) And I'm thinking of libfm1.0 for 1.0 series, libfm1.1 for 1.1, etc., i.e. symlinks will be /usr/include/libfm -> /usr/include/libfm1.0 /usr/lib/pkgconfig/libfm -> /usr/lib/pkgconfig/libfm1.0 I want opinions from all of you. What do you think? Do you have any objections on that? With the best wishes. Andriy. |
From: Julien L. <gi...@ub...> - 2012-08-14 20:51:27
|
Le 08/09/2012 01:21 PM, Andrej N. Gritsenko a écrit : > I want opinions from all of you. What do you think? Do you have any > objections on that? IMO, it sounds too much effort and complexity for a very few advantages. Usually, users have the stable version, or the unstable one (development version), but rarely both. And tweaking the way of building libfm is probably limited to the devs, which probably have already a modified version of the library on their system. It will also make the life of the packagers less nice, as we probably never want to ship 2 different versions of libfm in 1 release of a distribution. Regards, Julien Lavergne |
From: Andrej N. G. <an...@re...> - 2012-08-14 22:53:45
|
Hello! Julien Lavergne has written on Tuesday, 14 August, at 22:51: >Le 08/09/2012 01:21 PM, Andrej N. Gritsenko a écrit : >> I want opinions from all of you. What do you think? Do you have any >> objections on that? >IMO, it sounds too much effort and complexity for a very few advantages. The main advantage is to help developers have it in default search path (library already is in but headers are not). And anyway the way it is now does not have any advantages unfortunately. About too much effort - it will consist only of few lines changed. I already made a package with this locally when I made my local tests since I don't like idea to create configure file just to test something, it's just overkill. ;-) So believe me, it is NOT too much effort. >Usually, users have the stable version, or the unstable one (development >version), but rarely both. And tweaking the way of building libfm is >probably limited to the devs, which probably have already a modified >version of the library on their system. >It will also make the life of the packagers less nice, as we probably >never want to ship 2 different versions of libfm in 1 release of a >distribution. As for packagers - you're completely right, you'll probably never ship 2 different versions of development package (since package manager would not allow install of 2 packages of the same name but different versions) so nothing will be changed for you, it is the change only for developers sake. With best regards. Andriy. |
From: Martin B. / b. <br...@bs...> - 2012-08-14 22:15:32
|
On Thu, 9 Aug 2012, Andrej N. Gritsenko wrote: > 4. The debian bug tracker have a bug about libfm headers already. This is not a argument, please explain how this is important. (for the question you ask I have no opinion. I believe others will care more.) -- /brother http://martin.bagge.nu SSL is invulnerable to man-in-the-middle attacks. Unless that man is Bruce Schneier. |