[PATCH util-modular 5/9] build.sh: add the remaining xorg lib(s)

[Emil Velikov]

On 27 February 2017 at 02:10, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> On Tue, Feb 14, 2017 at 10:11:09PM +0000, Emil Velikov wrote:
>> Thanks for having a look Alan.
>>
>> On 14 February 2017 at 16:31, Alan Coopersmith
>> <alan.coopersmith at oracle.com> wrote:
>> > This one seems useful/important:
>> >> +    build lib libXpresent
>> >
>> > Are you using the github version for this since it moved off fd.o?
>> >> +    build lib libxkbcommon
>> >
>> > I don't know what this is:
>> >> +    build lib libXrandrUtils
>> >
>> > This was a student project that I don't know if it ever got finished or
>> > adopted:
>> >> +    build lib libxcwm
>> >
>> > The rest are deprecated/obsolete/unused:
>>
>> Rather than scattering, I'll try to sum it up here:
>>
>> Patches 4-9 are sort of RFC, at least for the time being.
>> IMHO it makes sense to have all the repos listed since amongst others
>> it makes it easy to track/sync the list via the diff command provided.
>>
>> Now to the moved/foo/bar repos. One idea boils down to having a checked-in file.
>>  - moved - "moved-to" -> git clone ... `cat $ROOT/$MODULE/moved-to`
>> and act accordingly
>>  - no longer maintained - "unmaintained" can be used to
>> a) track if configure.ac has been updated (returns unique error code)
>> b) warn early when explicitly requesting to configure/build the module, other
>>  - odd repos - xorg/xserver-test anyone, xproto, other - nuke them ;-)
>
> What's the end goal of this though? Having configure nuke out seems like the
> most sensible solution for any repository that has surpassed its useful
> life. And *not* having it in the build.sh script is likely better to avoid
> erroneous clones than having an external file that tracks this.
>
Having the extra checkout is negligible comparing to:
 - we can diff (see the command in patch 4) the existing tree against
the current contents
 - we can automatically redirect moved repos (git clone `cat MOVED`)
 - we can do a sanity check (that configure bails out) for deprecated repos
 - the above two can be synced with a third party file (MAINTAINERS?)
 - but in general relying solely on MAINTAINERS (or anything that's
outside of the respective repo) will lead end up horrilbly out of date

> We do have a MAINTAINERS file somewhere, in theory that could already be
> used to list deprecated repositories.
>
The MAINTAINERS is one such example.

Actually skimming through the file we can even feed/cross reference
the information between it and the git config of the repos.
Something like -> git config  --get sendemail.cc $MAINTAINER


>> "Fixing" things roughly like above will take some time, but I wouldn't
>> mind helping out every now and then.
>
> This is something where I think we'd have to have everything in place in one
> go. Because if we merge the patches 4-9 but then not update the rest for
> another year, we'll have a year's worth of people checking out repositories
> that they don't need. Or worse, repositories, that break the build.sh run.
>
Fully agree - we cannot merge 4-9 as-is. I'm mostly looking for a
confirmation that I'm not completely loosing it and the (above) plan
sounds reasonable.

-Emil