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

[Martin-Éric Racine]

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?

NEWS: I'm partial to completely deleting this one and instead including
the NEWS in the commit message for each release. Comments?

README: seems up-to-date, except perhaps for the minimal X version; does
it need to match our X macro version?

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.

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

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

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

Martin-Éric