Mario Klebsch wrote: > Am Samstag, 10.01.04 um 13:40 Uhr schrieb Warren Turkal: > I never understood why so many people consider these autotools easier > to use than the imake system. Imake (or to be precise, the config files > included with X11) knows everything about the local X11 installation, > where configure has to guess and far too often guesses wrong. I really > do see no benefit in not using the imake system and I must admit that I > do not understand why configure does not use an Imakefile to find out > all the details needed to compile X11 programs on a given platform.
Pkgconfig is meant to take care of providing these settings without resorting to brute force checks or manually assigning lib location and whatnot. It also provides a really simple autoconf macro in order to use this functionality. An example from our lib build system: PKG_CHECK_MODULES(X11, xextensions xtrans xcb) This is used to determine the presence of the the xextention, xtrans, and xcb libs. *snip* > I hope X11 will keep the imake system. However if these efforts do get > configure to reliably detect the X11 specific settings, I would be > happy if this stuff is included in X11, so this pain finally get to an > end. Detecting it with the brute force of old days is crappy. If someone has X installed in /usr/local/X/ instead of /usr/X11R6/, I don't think that autoconf will detect the libs right without pkgconfig or using a custom macro. pkgconfig is a solution that can be used in more than just one project and is an easier solution to maintain. I tried a while back to get the libX11 in XF86 to include pkgconfig files needed to do this kind of thing. You all didn't see the point. I would still like to do that if there is any interest in making autotools work better with the XF86 built environment. > I still do not see, what is gained by this. As long, as the X11 > protocol is still used, it should not matter, which libs are linked. > BTW, it is easy to build everything of X11 except the Xserver. A simple > setting in site.def will do the job. Different implementations of libX11 can be tested without copying them into the tree and making sure that they have the same build system as XF86. > You could just install X11 somewhere on your system, make a copy of > xmkmf, imake and its configuration, edit the config files according to > your needs and compile the X11 programs using your new configuration. > No changes should be needed anywhere inside of the X11 application > directories. > > As a starting point you could pick up xlogo or xlock and compile them > stand alone. just type Well, how do I do that and easily make them link against my libs? Can I do this for the entire tree? > and it should do the job. I just did it for xclock and it worked fine. > Just for curiosity, I tried it witk Xaw and it worked, too. Sou it > seems, you can also build the X11 libs against your imake system and > your config files as well as individual libs agaainst the rest of your > package. So, now can I stop libX11 from compiling in the XF86 tree and force the tree to use an external libX11? > I also tried it for lib/X11, but it failed. :-( It somehow references > source files in a sibling directory named xtrans. xtrans itself does > contain some code but does not produce anything when I run make. xmkmf > simply creates some symbolic links. I am not sure, wether compiling > libX11 standalone is is supposed to work. I am not only trying to use your Xlib with a new build system. We have a prototype of the XCB/XCL implementation that I would like to use during the build process. We have it building fine with autotools. How can I make the XF86 tree use this? > Do you have the imake build system? X11 applications generally have an > Imakefile, so you must have xmkmf, imake and the config files to build > it. The only X11 apps that I know of that use imake are the ones that come with XF86. KDE, Gnome, and <most oss projects> use autotools. With pkgconfig support, it should make it easier in the future for them to detect what they need. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
