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 <[email protected]>: >>>> 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 > > _______________________________________________ Xorg-driver-geode mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-geode
