[Xorg-driver-geode] current status of Geode X.org driver

[Gaetan Nadon]

On 13-10-02 10:54 AM, Martin-Éric Racine wrote:
> ti, 2013-10-01 kello 19:14 -0400, Gaetan Nadon kirjoitti:
>> On 13-10-01 11:11 AM, Martin-Éric Racine wrote:
>>
>>> 2013/10/1 Gaetan Nadon <memsize at videotron.ca>:
>>>> If you are going for a round of upgrades, here are some suggestions.
>>>>
>>>> COPYING:    review the content of the file to insure it matches the
>>>> copyright statements in the source code (which may have changed).
>>>> NEWS:         review content
>>>> README:    review content
>>>> TODO:        dating from 2007. Update or delete
>>> Agreed.
> COPYING: didn't we have talks about semi-automating this by extracting
> the name+address of committers from Git log, at some point?
I don't think this can be automated at a reasonnable cost. For having
done a good number of those.
>
> NEWS: I'm partial to completely deleting this one and instead including
> the NEWS in the commit message for each release. Comments?
No objections.
>
> README: seems up-to-date, except perhaps for the minimal X version; does
> it need to match our X macro version?
Nope.
>
> TODO: most of this remains current, AFAIK. Lots of nice things simply
> never got implemented. This is a video module that badly needs new
> contributors to the actual driver code.
Ok.
>
>>>> I can help with the m4 directory, there are some pitfalls to avoid, as
>>>> simple as it may look.
>>> I borrowed the attached bits from xf86-video-intel. Does this look good?
>> They have a macro checked-in git in the m4 dir. 
> Correct. It looked like a useful one so I borrowed it as-is.
Are you talking about ac_define_dir.m4? If so, please don't use it. It
creates absolute paths at configure time which are not reliable. It's a
workaround to an automake architecture. It's an old version anyway. The
correct version is in the xserver. There are a few xorg modules using
it, but it is not something to be promoted.
>
>> You cannot have an empty m4 dir under git control. Some project put a
>> dummy README file but I prefer putting a .gitignore there containing
>> the libtool stuff to ignore:
>>
>> libtool
>> libtool.m4
>> ltmain.sh
>> lt~obsolete.m4
>> ltoptions.m4
>> ltsugar.m4
>> ltversion.m4
> I agree, since those are copied at libtool run time.
>
>> Given you don't have a macro of your own in m4, you won't need
>> ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS} -I m4 in the toplevel makefile.
>> Starting automake 1.14, implementation changes make this variable
>> obsolete. 
> If having that variable improves back-portability and doesn't adversely
> affect anything, I'd rather keep it.
If you have a macro in m4, then you need it. I thought you didn't.
>
>> While we are talking build, I have a couple of questions;
>>              1. Is there anything that would make it difficult for
>>                 Geode to move up to libtool 2.2?
>>              2. If yes, and if the rest of xorg was to move to libtool
>>                 2.2, would that be a problem for building geode with
>>                 libtool 1.5? (do you typically build geode only or do
>>                 you also build other modules like libraries, apps,
>>                 server, etc...)
> Lots of OEM's base their whole firmware image on some obsolete codebase.
> They only ever upgrade key components (such as this Geode driver) when
> it improves performance but typically build it against their old X. The
> same logic often applies to build tools: proven good over shiny and new.
> This being said, libtool 2.2 appears to be as common as autoconf >2.60,
> so if anyone sees a compelling to mass-upgrade X components, why not.
Ok, thanks


So that pretty much covers it.
>
> Martin-Éric
>
>