[Xcb] [PATCH] libxcb: autotools changes

Eamon Walsh ewalsh at tycho.nsa.gov
Mon Dec 17 14:05:11 PST 2007


Jamey Sharp wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Eamon! I finally got around to committing your patch, and then
> discovered you already did it. :-) Thanks.
>   

Thanks for your review and comments.

> On 12/4/07, Eamon Walsh <ewalsh at tycho.nsa.gov> wrote:
>   
>> Well, I do want my extension in-tree, just disabled by default.
>>     
>
> Huh. I don't understand why; can you give some rationale?
>   

Packaging/maintenance.  It would be a lot of work to keep it as a 
separate upstream.  Even with a shell script or Makefile allowing 
out-of-tree builds, I'd have to track changes to the XML schema as they 
occured and apply them.  Extension libraries link with the base 
libxcb.so so it would be required anyway for anyone to build or use it.

I'm not trying to throw anything over the wall here, you can put my name 
in the maintainers file or whatever.  It would just make my life easier 
not to have to support it as a separate upstream.

>> Anyway I've fixed the issues you pointed out and the new patch is
>> below.  I disabled an extension (shape) and ran make distcheck and it
>> generated tarballs without error...but if you do want the pc.in's
>> installed unconditionally let me know.
>>     
>
> I don't understand why, but I guess all the .pc.in files are being
> distributed even if they're conditionally excluded from EXTRA_DIST. So
> `make dist` after configure has been called with some --disable flags
> still produces a tarball that can be used when configured with all
> extensions enabled.
>
> Which means this is OK, for some reason I don't know.
>   

According to [1], inputs to AC_CONFIG_FILES are automatically 
distributed.  The whole EXTRA_DIST thing is redundant, it looks like, 
since they are all passed to AC_CONFIG_FILES on configure.ac:136.

>   
>> But to support out-of-tree experimentation, you can have libxcb
>> install the required build machinery in /usr/share/xcb/devel and
>> provide a Makefile the user can use to build a library.  The user
>> would do something like:
>>
>> $ cd $HOME/mystuff
>> $ vi foo.xml
>> $ make -f /usr/share/xcb/devel/Makefile
>> Building foo library, blah blah
>> $ make -f /usr/share/xcb/devel/Makefile install
>> Installing foo library, blah blah
>>     
>
> That seems like the general shape of a solution, yes. (I'd probably use
> a simple shell script rather than a Makefile, though, I think...)
> Questions remain, though, such as what the .pc file should look like
> when generated by this process and how to version the generated
> libraries and .pc files.
>   

The prefix stuff in the .pc file could come from the environment or 
arguments to the shell script.  The rest, including the version number, 
can come from the XML description.

[1] http://www.gnu.org/software/automake/manual/html_node/Requirements.html

-- 
Eamon Walsh <ewalsh at tycho.nsa.gov>
National Security Agency



More information about the Xcb mailing list