Hello,
The attached patch makes VDR's Makefile use pkgconfig for finding libs and include dirs of freetype and fontconfig instead of making assumptions.
On 03/06/08 20:37, Ville Skyttä wrote:
Hello,
The attached patch makes VDR's Makefile use pkgconfig for finding libs and include dirs of freetype and fontconfig instead of making assumptions.
How about putting that stuff at the same place everywhere? Why must it have to be somewhere else on every system?
Klaus
En/na Klaus Schmidinger ha escrit:
On 03/06/08 20:37, Ville Skyttä wrote:
Hello,
The attached patch makes VDR's Makefile use pkgconfig for finding libs and include dirs of freetype and fontconfig instead of making assumptions.
How about putting that stuff at the same place everywhere? Why must it have to be somewhere else on every system?
If you use packages provided by your linux distribution, usually include files are in /usr/include and libraries are in /usr/lib, while if you compile the source tarball yourself they go in /usr/local/include and /usr/local/lib or wherever you decide to put them (if, e.g., you're trying another version while you're keeping the old one, though I don't know if pkg-config will handle this case)
Bye
On 03/07/08 08:44, Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
On 03/06/08 20:37, Ville Skyttä wrote:
Hello,
The attached patch makes VDR's Makefile use pkgconfig for finding libs and include dirs of freetype and fontconfig instead of making assumptions.
How about putting that stuff at the same place everywhere? Why must it have to be somewhere else on every system?
If you use packages provided by your linux distribution, usually include files are in /usr/include and libraries are in /usr/lib, while if you compile the source tarball yourself they go in /usr/local/include and /usr/local/lib or wherever you decide to put them (if, e.g., you're trying another version while you're keeping the old one, though I don't know if pkg-config will handle this case)
The root of the whole problem here IMHO is freetype2's weird way of handling its include files. I never understood why they had to use these strange macros for the includes. An application using freetype2 shouldn't have to add -I/usr/include/freetype2 to its include path. It should be possible to do
#include <freetype2.h>
and the rest should be handled inside that file. No weird macros, no extra include paths.
BTW: whether an include file is in /usr/include or /usr/local/include doesn't matter - it is already found in both cases, without any extra effort. And the one in /usr/local/include takes precedence, just as one would ecpect.
Klaus
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: 20080307114057.C44873@unqrf.nqzva.sez2
On Thu, 6 Mar 2008, Klaus Schmidinger wrote:
On 03/06/08 20:37, Ville Skyttä wrote:
Hello,
The attached patch makes VDR's Makefile use pkgconfig for finding libs and include dirs of freetype and fontconfig instead of making assumptions.
How about putting that stuff at the same place everywhere? Why must it have to be somewhere else on every system?
Klaus,
how about accepting the case, that the world has more than one Linux distribution and in addition, there is not only Linux where VDR can run on. How about beeing a little bit less ignorant when it comes to VDR and portability. What do you think why we have tools like pkg-config or autotools and so many projects make use of it? Because its funny? I don't think so!
What's the big deal with Villa's proposal to change two lines in the Makefile when it breaks nothing for you and makes life easier for other users?
Sorry for beeing harsh Joerg
- -- The beginning is the most important part of the work. -Plato
On 03/07/08 13:17, Joerg Pulz wrote:
Content-ID: 20080307114057.C44873@unqrf.nqzva.sez2
On Thu, 6 Mar 2008, Klaus Schmidinger wrote:
On 03/06/08 20:37, Ville Skyttä wrote:
Hello,
The attached patch makes VDR's Makefile use pkgconfig for finding libs and include dirs of freetype and fontconfig instead of making assumptions.
How about putting that stuff at the same place everywhere? Why must it have to be somewhere else on every system?
Klaus,
how about accepting the case, that the world has more than one Linux distribution and in addition, there is not only Linux where VDR can run on. How about beeing a little bit less ignorant when it comes to VDR and portability. What do you think why we have tools like pkg-config or autotools and so many projects make use of it? Because its funny? I don't think so!
What's the big deal with Villa's proposal to change two lines in the Makefile when it breaks nothing for you and makes life easier for other users?
See my reply to Luca.
Instead of having all applications work around freetyp2's weird include macro stuff, why not complain to the freetype2 people and have them provide just a plain old <freetype2.h> that can be included like any other header file?
Sorry for being ignorant, but I have this tendency to try to solve problems at their root.
Klaus
On Friday 07 March 2008, Klaus Schmidinger wrote:
Instead of having all applications work around freetyp2's weird include macro stuff, why not complain to the freetype2 people and have them provide just a plain old <freetype2.h> that can be included like any other header file?
Sorry for being ignorant, but I have this tendency to try to solve problems at their root.
FWIW, I think providing a pkgconfig file is very much a "root" solution (ditto $foo-config scripts, but *.pc are much simpler to write and read and have a unified interface). Lots of library packages (and also some others) provide them nowadays which is great, and has made the things you express dissatisfaction with in the above as well as other similar ones pretty much moot.
In fact, I think VDR should also provide a *.pc file. I ship one in Fedora's VDR packages, and a good deal of it would be applicable to upstream VDR too. Just let me know if you're interested and I'll have a look at making a upstreamable version of it.
On 03/07/08 18:48, Ville Skyttä wrote:
On Friday 07 March 2008, Klaus Schmidinger wrote:
Instead of having all applications work around freetyp2's weird include macro stuff, why not complain to the freetype2 people and have them provide just a plain old <freetype2.h> that can be included like any other header file?
Sorry for being ignorant, but I have this tendency to try to solve problems at their root.
FWIW, I think providing a pkgconfig file is very much a "root" solution (ditto $foo-config scripts, but *.pc are much simpler to write and read and have a unified interface). Lots of library packages (and also some others) provide them nowadays which is great, and has made the things you express dissatisfaction with in the above as well as other similar ones pretty much moot.
In fact, I think VDR should also provide a *.pc file. I ship one in Fedora's VDR packages, and a good deal of it would be applicable to upstream VDR too. Just let me know if you're interested and I'll have a look at making a upstreamable version of it.
If this is as simple as putting another file into the VDR source directory (and leaving everything else as is), please send me that file and I'll take a look.
Klaus
Ville Skyttä ville.skytta@iki.fi wrote:
FWIW, I think providing a pkgconfig file is very much a "root" solution (ditto $foo-config scripts, but *.pc are much simpler to write and read and have a unified interface). Lots of library packages (and also some others) provide them nowadays which is great, and has made the things you express dissatisfaction with in the above as well as other similar ones pretty much moot.
i can't agree more.
In fact, I think VDR should also provide a *.pc file. I ship one in Fedora's VDR packages, and a good deal of it would be applicable to upstream VDR too. Just let me know if you're interested and I'll have a look at making a upstreamable version of it.
i would even say VDR is broken in the way it handles plaugins. VDR's Makefile should install all exported vdr headers in $(PREFIX)/include/vdr and provide a vdr.pc file (as you suggest). then plugins could be buildable outside of VDR's source directory and install themself in $(PREFIX)/lib/vdr. as any other plugin capable program out there i know.
just my 2 cents ... clemens
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, 8 Mar 2008, Clemens Kirchgatterer wrote:
Ville Skyttä ville.skytta@iki.fi wrote:
FWIW, I think providing a pkgconfig file is very much a "root" solution (ditto $foo-config scripts, but *.pc are much simpler to write and read and have a unified interface). Lots of library packages (and also some others) provide them nowadays which is great, and has made the things you express dissatisfaction with in the above as well as other similar ones pretty much moot.
i can't agree more.
In fact, I think VDR should also provide a *.pc file. I ship one in Fedora's VDR packages, and a good deal of it would be applicable to upstream VDR too. Just let me know if you're interested and I'll have a look at making a upstreamable version of it.
i would even say VDR is broken in the way it handles plaugins. VDR's Makefile should install all exported vdr headers in $(PREFIX)/include/vdr and provide a vdr.pc file (as you suggest). then plugins could be buildable outside of VDR's source directory and install themself in $(PREFIX)/lib/vdr. as any other plugin capable program out there i know.
just my 2 cents ... clemens
Clemens,
you are so damn right!
+1 from my side
Joerg
- -- The beginning is the most important part of the work. -Plato
On 03/08/08 11:54, Clemens Kirchgatterer wrote:
Ville Skyttä ville.skytta@iki.fi wrote:
FWIW, I think providing a pkgconfig file is very much a "root" solution (ditto $foo-config scripts, but *.pc are much simpler to write and read and have a unified interface). Lots of library packages (and also some others) provide them nowadays which is great, and has made the things you express dissatisfaction with in the above as well as other similar ones pretty much moot.
i can't agree more.
In fact, I think VDR should also provide a *.pc file. I ship one in Fedora's VDR packages, and a good deal of it would be applicable to upstream VDR too. Just let me know if you're interested and I'll have a look at making a upstreamable version of it.
i would even say VDR is broken in the way it handles plaugins. VDR's Makefile should install all exported vdr headers in $(PREFIX)/include/vdr and provide a vdr.pc file (as you suggest). then plugins could be buildable outside of VDR's source directory and install themself in $(PREFIX)/lib/vdr. as any other plugin capable program out there i know.
I don't care what the "install" targets actually do, since I dont use them. So if you want to change that, suggest a patch. However, it must still be possible to build and run plugins in VDR/PLUGINS/... as it is right now (without using "install-plugins").
Klaus
Joerg Pulz wrote:
What do you think why we have tools like pkg-config or autotools and so many projects make use of it? Because its funny? I don't think so!
What's the big deal with Villa's proposal to change two lines in the Makefile when it breaks nothing for you and makes life easier for other users?
#>pkg-config --libs freetype2 fontconfig -bash: pkg-config: command not found
- no comment -
Cheers,
Udo
Udo Richter udo_richter@gmx.de wrote:
#>pkg-config --libs freetype2 fontconfig -bash: pkg-config: command not found
- no comment -
i could as easily argue with:
make
bash: make: command not found
pkg-config is no exotic dependency that we have good reason to avoid.
clemens
Clemens Kirchgatterer wrote:
pkg-config is no exotic dependency that we have good reason to avoid.
I know that its easy to install that package. (Though I wonder whether the linvdr guys agree.) My point is just that its not a change-one-line-and-all-will-be-happy, it does add one more to the build dependency.
Basically we have two options here: 1 - keep a hard coded include path. That way some people would need to set up additional include paths manually. 2 - Use pkg-config. This way some people would need to install pkg-config to build VDR.
The question is: Which way would spoil more people? At least for me (s/me/Debian/), the default paths seem to be just fine. So I wonder: How many people need to set up different include paths?
Or even better: Is there a third way that works for both?
Cheers,
Udo
Udo Richter udo_richter@gmx.de wrote:
Or even better: Is there a third way that works for both?
as i have written in my RFC there is:
freetype-config
On 03/08/08 17:43, Udo Richter wrote:
Clemens Kirchgatterer wrote:
pkg-config is no exotic dependency that we have good reason to avoid.
I know that its easy to install that package. (Though I wonder whether the linvdr guys agree.) My point is just that its not a change-one-line-and-all-will-be-happy, it does add one more to the build dependency.
Basically we have two options here: 1 - keep a hard coded include path. That way some people would need to set up additional include paths manually. 2 - Use pkg-config. This way some people would need to install pkg-config to build VDR.
The question is: Which way would spoil more people? At least for me (s/me/Debian/), the default paths seem to be just fine. So I wonder: How many people need to set up different include paths?
Or even better: Is there a third way that works for both?
I'll add a section to the Make.config file for "packages with non-default locations", like
INCLUDES += -I/usr/include/freetype2
Then everybody can overwrite that in whatever way fits their needs.
I still believe, though, that freetype2's include files are broken. A simple '#include <freetype2.h>' should be enough. If their header file(s) would behave like the rest, we wouldn't have this discussion.
Klaus
Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I still believe, though, that freetype2's include files are broken. A simple '#include <freetype2.h>' should be enough. If their header file(s) would behave like the rest, we wouldn't have this discussion.
no. pkg-config and freetype-config have absolutly nothing to do with that. i think nearly every "obtional" library has one of these to provide a way to find them at compile and link time. please see the output of: ls /usr/bin/*-config
clemens
On 03/08/08 19:12, Clemens Kirchgatterer wrote:
Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I still believe, though, that freetype2's include files are broken. A simple '#include <freetype2.h>' should be enough. If their header file(s) would behave like the rest, we wouldn't have this discussion.
no. pkg-config and freetype-config have absolutly nothing to do with that. i think nearly every "obtional" library has one of these to provide a way to find them at compile and link time. please see the output of: ls /usr/bin/*-config
But would it kill anybody to simply have all header files at a standard place (/usr/include and /usr/local/include)? Why should every application go on a scavenger hunt to find all the header files it needs?
Anyway, it's going to be in Make.config, then you can do whatever you like ;-)
Klaus
Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 03/08/08 19:12, Clemens Kirchgatterer wrote:
Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I still believe, though, that freetype2's include files are broken. A simple '#include <freetype2.h>' should be enough. If their header file(s) would behave like the rest, we wouldn't have this discussion.
no. pkg-config and freetype-config have absolutly nothing to do with that. i think nearly every "obtional" library has one of these to provide a way to find them at compile and link time. please see the output of: ls /usr/bin/*-config
But would it kill anybody to simply have all header files at a standard place (/usr/include and /usr/local/include)?
yes it would. how would you install different versions of the same libraries (with their headers) if it wasn't in different paths? and what about cross compilers? the possibillity of having libs and headers in different places is a very important feature, not an anoying bug.
Why should every application go on a scavenger hunt to find all the header files it needs?
see above. anyway, thats the way it was since many many years for good reasons. it's the standard way of finding compiler and linker flags for libraries and you like obeying standards, don't you?
SCNR... clemens
Clemens Kirchgatterer wrote:
But would it kill anybody to simply have all header files at a standard place (/usr/include and /usr/local/include)?
yes it would. how would you install different versions of the same libraries (with their headers) if it wasn't in different paths? and what about cross compilers? the possibillity of having libs and headers in different places is a very important feature, not an anoying bug.
Using different versions of a library or cross-compiling will always require manual setup of include paths anyway. How should any magic configuration tool know which of the installed headers should be used anyway?
There is _one_ currently installed default version of the headers for this machine, and the question is why these headers are not at a default location, esp. since the binaries seem to be at a default location, or?
(btw. in case I do have two sets of include files and I need to switch between them: Changing an INCLUDE= is pretty obvious, but how do I tell pkg-config or freetype-config what I want to compile?)
Cheers,
Udo
On Sun, Mar 9, 2008 at 10:50 AM, Udo Richter udo_richter@gmx.de wrote:
There is _one_ currently installed default version of the headers for this machine, and the question is why these headers are not at a default location, esp. since the binaries seem to be at a default location, or?
no, think about having two versions of the same library stack in for example /opt1 and /opt2. both prefixes contain the usual directory structure bin, lib, include, share, ... if i want to compile software using the libs (and headers) of opt1 i only have to do "PKG_CONFIG_PATH=/opt1 make" and to start that program "LD_LIBRARY_PATH=/opt1 prog". given the Makefile of prog uses pkg-config properly.
(btw. in case I do have two sets of include files and I need to switch between them: Changing an INCLUDE= is pretty obvious, but how do I tell pkg-config or freetype-config what I want to compile?)
see above. as each version of the libraries is compiled with different prefixes (and maybe even with different dependencies) they come with their very own *.pc or *-config file. to switch between them at compile time, i simply have to manypulate PKG_CONFIG_PATH (or PATH in case of *-config) and at runtime i have to fix the linker path with LD_LIBRARY_PATH.
there is another argument for pkg-config we havent talked about yet. the link dependencies. type 'freetype-config --libs' and it will most likly print '-lfreetype -lz' but only if you have compiled freetype with zlib support. or another dependency vdr does not handle properly: ncurses. on my system 'ncurses5-config --cflags --libs' prints -L/usr/lib -lncurses -ldl -I/usr/include/ncurses, but it could as easily be somewhere else.
best regards ... clemens
Hi,
Am Montag, den 10.03.2008, 11:39 +0100 schrieb clemens kirchgatterer:
there is another argument for pkg-config we havent talked about yet. the link dependencies. type 'freetype-config --libs' and it will most likly print '-lfreetype -lz' but only if you have compiled freetype with zlib support. or another dependency vdr does not handle properly
That the point, for the plugin vdr-image[¹] exist same problems with libavcodec from ffmpeg. This library has many compile options. I thick the best solution are "pkg-config" to handle includes and libraries dependencies in a proper style.
Andreas
My sample with libavcodec and optionally libswscale and libexif [¹] http://svn.berlios.de/svnroot/repos/vdr-image/trunk/Makefile
clemens kirchgatterer wrote:
structure bin, lib, include, share, ... if i want to compile software using the libs (and headers) of opt1 i only have to do "PKG_CONFIG_PATH=/opt1 make" and to start that program "LD_LIBRARY_PATH=/opt1 prog". given the Makefile of prog uses pkg-config properly.
And thats so much better than make INCLUDES=/opt1/usr/include?
My point is: There's one version of the libs that is in the default library search path. Shouldn't there also be one header in the default header search path then?
Btw. do I need to call /opt1/usr/bin/freetype-config? or will any freetype-config be ok?
Cheers,
Udo
On Monday 10 March 2008, Udo Richter wrote:
clemens kirchgatterer wrote:
structure bin, lib, include, share, ... if i want to compile software using the libs (and headers) of opt1 i only have to do "PKG_CONFIG_PATH=/opt1 make" and to start that program "LD_LIBRARY_PATH=/opt1 prog". given the Makefile of prog uses pkg-config properly.
And thats so much better than make INCLUDES=/opt1/usr/include?
If "make INCLUDES=..." or manually changing INCLUDES in Makefile [0] works better for you than using pkg-config, by all means use/do it. The patch I posted does not prevent that; it's possible just like it was before the patch.
The intention of the patch is to make it more likely that there would be one thing less to touch when building VDR for most users. I think that's much more likely when using pkg-config than when hardcoding stuff; that's why I'm suggesting it to be used by default rather than telling people to build with "make INCLUDES=$(pkg-config --cflags-only-I freetype2 fontconfig) ..."
My point is: There's one version of the libs that is in the default library search path. Shouldn't there also be one header in the default header search path then?
Why do you assume that there are any versions of the libs in default lib search paths? There might not be any.
In addition to setting include dirs, the pkg-config patch also takes care of library names and library dirs. It could also take care of other non"-I" CFLAGS possibly needed (replace --cflags-only-I with --cflags, I didn't do that because it doesn't seem well placed in a variable called INCLUDES and my intention was not to make too many changes to Makefile). And it could even handle RPATHs if the lib dirs are not in default search paths, but that's theoretical/guesswork - I haven't checked if any *.pc does anything like that.
Btw. do I need to call /opt1/usr/bin/freetype-config? or will any freetype-config be ok?
If using pkg-config, I don't know why you'd call freetype-config at all.
On Mon, Mar 10, 2008 at 7:31 PM, Udo Richter udo_richter@gmx.de wrote:
clemens kirchgatterer wrote:
structure bin, lib, include, share, ... if i want to compile software using the libs (and headers) of opt1 i only have to do "PKG_CONFIG_PATH=/opt1 make" and to start that program "LD_LIBRARY_PATH=/opt1 prog". given the Makefile of prog uses pkg-config properly.
And thats so much better than make INCLUDES=/opt1/usr/include?
yes it is, because 1. pkg-config will handle the linker flags as well (otherwise you will have to give gcc the correct -L/opt1/usr/lib path), an 2. dealing with pkg-config is the standard way of doing this kind of things.
My point is: There's one version of the libs that is in the default library search path. Shouldn't there also be one header in the default header search path then?
why should the libraries (and their headers) be installed in the default search path in the first place?
Btw. do I need to call /opt1/usr/bin/freetype-config? or will any freetype-config be ok?
/opt1/usr/bin/freetype-config
thats one of the reasons why pkg-config is prefered. it has a distinctiv $PKG_CONFIG_PATH and does not depend on $PATH.
geetings ... clemens
On Sat, 2008-03-08 at 19:12 +0100, Clemens Kirchgatterer wrote:
Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I still believe, though, that freetype2's include files are broken. A simple '#include <freetype2.h>' should be enough. If their header file(s) would behave like the rest, we wouldn't have this discussion.
no. pkg-config and freetype-config have absolutly nothing to do with that. i think nearly every "obtional" library has one of these to provide a way to find them at compile and link time. please see the output of: ls /usr/bin/*-config
I don't know make's syntax, but why not do something like:
in shell: $(freetype-config 2>/dev/null --cflags || echo /usr/include/freetype3)
As I said I don't know make's config but it might be: $(shell freetype-config 2>/dev/null --cflags || echo /usr/include/freetype3)
clemens
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 03/08/08 15:01, Clemens Kirchgatterer wrote:
Udo Richter udo_richter@gmx.de wrote:
#>pkg-config --libs freetype2 fontconfig -bash: pkg-config: command not found
- no comment -
i could as easily argue with:
make
bash: make: command not found
How do you build VDR without 'make'?
Klaus
Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 03/08/08 15:01, Clemens Kirchgatterer wrote:
Udo Richter udo_richter@gmx.de wrote:
#>pkg-config --libs freetype2 fontconfig -bash: pkg-config: command not found
- no comment -
i could as easily argue with:
make
bash: make: command not found
How do you build VDR without 'make'?
my point was, that even make is no strict requiremant for building vdr, we could have a shell script as well or call gcc by hand. of course make makes life easier, so we use it. but so does pkg-config.
-
Andreas Brachold -
Clemens Kirchgatterer -
clemens kirchgatterer
-
Joerg Pulz -
Klaus Schmidinger -
Luca Olivetti -
Malcolm Caldwell -
Udo Richter -
Ville Skyttä