On Wed, 2009-12-02 at 17:36 -0800, Carl Worth wrote: > On Wed, 02 Dec 2009 16:22:39 -0500, Gaetan Nadon <[email protected]> > 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. >
No problem, I am learning a lot. > > Fedora states that their packages must comply with the File System > > Hierarchy Standard (http://www.pathname.com/fhs/). This standard states > > the location of files on the filesystem. For /usr/share > > (http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA) > > 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*. 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. > > 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 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. > But regardless, even if it were made entirely shareable, why not just > install to libdir like all the other pkg-config files? 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. > > 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? Not about saving disk. > > 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... I wish they would, this was the subject of another review... > > > 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. > 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. > If this ship sailed already with Xtrans, then that's unfortunate. I > probably would have complained then too if I had noticed... > I have not looked at xtrans, so I can't comment on their decision. > > 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. macros are not compiled, so no issues there (I think). > > -Carl 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
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
