<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Wed, 2009-12-02 at 17:36 -0800, Carl Worth wrote: <BLOCKQUOTE TYPE=CITE> <PRE> On Wed, 02 Dec 2009 16:22:39 -0500, Gaetan Nadon <<A HREF="mailto:gaetan.nadon@videotron.ca">gaetan.nadon@videotron.ca</A>> wrote: > I'd like to set aside the 'work required for the transition' issue and > focus on the architecture issue for a moment. Hi Gaetan, I hope I don't come across as incredibly dense, but I still don't understand why this .pc file must be installed in datadir not libdir. </PRE> </BLOCKQUOTE> No problem, I am learning a lot. <BLOCKQUOTE TYPE=CITE> <PRE> > Fedora states that their packages must comply with the File System > Hierarchy Standard (<A HREF="http://www.pathname.com/fhs/">http://www.pathname.com/fhs/</A>). This standard states > the location of files on the filesystem. For /usr/share > (<A HREF="http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA">http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA</A>) > it says: Yes, I'm familiar with the difference between "lib" and "share" according to the FHS. But just because this pkg-config file *could* go there doesn't mean that it *should*. </PRE> </BLOCKQUOTE> Since my last post, I looked around and figured out the distros flag some packages as arch:all. I think they are making a statement that the files in their package are architecture independent. When they do that and cross-compile it, it will not look in libdir. I noticed a couple of bugs where a distro asked upstream to put the .pc file in datadir because it does not cross-compile and they have to workaround. This was for xbitmaps and xproto. I would say that the pc file should where the OS is expecting them to be. If we don't, they have to make workarounds. If they follow the standard and we don't, we better have a good reason. <BLOCKQUOTE TYPE=CITE> <PRE> In fact, my xorg-macros.pc file installed in ${prefix}/share/xorg-macros.pc still refers to non-shareable directories, such as: libdir=${exec_prefix}/lib </PRE> </BLOCKQUOTE> The only statement needed is the docdir which is in share. I thought of not including any other one. This is a very interesting point you are making here. For arch-independent modules exec_prefix and libdir should not be specified. <BLOCKQUOTE TYPE=CITE> <PRE> But regardless, even if it were made entirely shareable, why not just install to libdir like all the other pkg-config files? </PRE> </BLOCKQUOTE> If my readings are correct, if the distros expect them to be arch-independent, they should go in datadir. I agree with you, it would be wasted work if only the macros pc file were to be in datadir. The other pc files won't all be in libdir. The subject of this discussion is not just about macros, but also about */proto, xbitmaps, cursor-themes and fonts. <BLOCKQUOTE TYPE=CITE> <PRE> Surely people will be building xorg-macros as just another one of many X.org modules all installed to some prefix, (and they would build all of these modules for each architecture of interest). And surely, you're not arguing that there's some important savings that would be obtained by carefully giving xorg-macros special treatment while building? </PRE> </BLOCKQUOTE> Not about saving disk. <BLOCKQUOTE TYPE=CITE> <PRE> And all of this is really to just copy in a generic INSTALL file that the autotools would copy in for us otherwise without any pkg-config file in the first place. My mind reels... </PRE> </BLOCKQUOTE> I wish they would, this was the subject of another review... <BLOCKQUOTE TYPE=CITE> <PRE> > It will be some work to make the change, but others have done it. I am > willing to create appropriate patches and collect the review tags. You can't patch everyone's build setup. That's stored in places like ~/.bashrc on random laptops all over the world. If we have to break the setup there should really be some demonstrable gain, and I just don't see it for xorg-macros.pc and XORG_INSTALL. </PRE> </BLOCKQUOTE> Already agreed, I would not do it just for macros. I think those setups will need to be updated anyway. I assume it's just updating a shell variable. <BLOCKQUOTE TYPE=CITE> <PRE> If this ship sailed already with Xtrans, then that's unfortunate. I probably would have complained then too if I had noticed... </PRE> </BLOCKQUOTE> I have not looked at xtrans, so I can't comment on their decision. <BLOCKQUOTE TYPE=CITE> <PRE> > So far we have one tool (cross-compile) that relies on this > architecture. How would cross-compiling not work if xorg-macros.pc were installed in libdir? Maybe this is the point I'm missing. </PRE> </BLOCKQUOTE> macros are not compiled, so no issues there (I think). <BLOCKQUOTE TYPE=CITE> <PRE> -Carl </PRE> </BLOCKQUOTE> I am sorry about the confusion between macros by itself and the */proto, etc... But one led to the other. I'd like comments on */proto and al and the arch:all packages from distros. That would be the deciding factor. In the mean time, no rush to change macros. Thanks for your time Gaetan </BODY> </HTML>