re: updating xf86-video-intel driver

[matthew green <mrg%eterna.com.au@localhost>]

> matthew green <mrg%eterna.com.au@localhost> wrote:
>     > Michael Richardson writes:
>     >> Is there some script/process/README that I'm missing on how the
>     >> xfreedesktop.org code is imported into the xsrc tree?
>     >> I see these dist/ subdirectories, but they seem to be neither a superset or
>     >> subset of what's out there in gitlab.freedesktop.org land.
>
>     > the upstream srcs are imported into
>
>     > xsrc/external/<lic>/<package>/dist
>
>     > with some pre-generated files stored along side the
>     > dist subdir in either include or src normally.
>
> Is this done by some script?
> Is there some record of what commitid was imported before?
> I want to update to latest to see if that solves some problems, but maybe
> I'll have to port just the specific fix.

i have a script that generates commands for me to diff
tarballs, prepare an import, and merge from previous version,
but it's tuned for my local setup (not good to commit.)

the record of what's in the tree is in the CVS tags and logs.
i keep meaning to put it all in something like doc/3RDPARTY.

>     > the build is over in src, though.  see:
>
>     > src/external/mit/xorg/server/drivers/xf86-video-intel*
>
>     > (there are two versions to choose from.)
>
> Thank you.
> Why two versions? Which is default?

the default is the new one, i think, but there are problems
that some have with it, that they do not have the with older
one.  plus, many are now using "modesetting" driver instead.

>     >> (I'm also perplexed by the xfree/xc references in xsrc/Makefile.
>     >> That must be old.  build.sh somehow works while not tripping there.
>     >> I don't quite understand what's going on. Used to be cd /usr/xsrc && make,
>     >> did something, but maybe those days are long over)
>
>     > someone (tm) should remove old xsrc/xfree refs.  you can
>     > trigger something similiar to the old "make" in xsrc with
>     > a "nbmake-foo build" in src/external/mit/xorg as a toplevel.
>
> thank you, that should be shorter :-)
> At present, I see issues/conflicts with deprecated warnings (vs -Werrors) in
> the code.

in general, we avoid changing upstream code to fix warnings
unless they're real bugs, but prefer to disable them as
warnings or even ignore totally.