[Xcb] [PATCH] libxcb: autotools changes

[Eamon Walsh]

Eamon Walsh wrote:
> 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.
>>     

In the absence of further debate, I'm going to push this up later in the 
week.  It will be disabled by default, so it shouldn't affect anyone who 
doesn't wish to use it.

And when there is support for building out-of-tree libraries, I won't 
object to revisiting whether it should be kicked out into its own upstream.

>>   
>>     
>
> 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