| Message ID | 1357856613-14866-1-git-send-email-damien.lespiau@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Jan 10, 2013 at 10:23:31PM +0000, Damien Lespiau wrote: > This is pretty much deprecated and automake includes a better equivalent > when maintainer's mode is not used. > > Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> What about moving gen4asm into a subdir of i-g-t? With git filter-branch we could even retain the entire history .... -Daniel > --- > autogen.sh | 2 +- > configure.ac | 2 -- > 2 files changed, 1 insertions(+), 3 deletions(-) > > diff --git a/autogen.sh b/autogen.sh > index 904cd67..354f254 100755 > --- a/autogen.sh > +++ b/autogen.sh > @@ -9,4 +9,4 @@ cd $srcdir > autoreconf -v --install || exit 1 > cd $ORIGDIR || exit $? > > -$srcdir/configure --enable-maintainer-mode "$@" > +$srcdir/configure "$@" > diff --git a/configure.ac b/configure.ac > index 0b4427c..a195505 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -10,8 +10,6 @@ AC_INIT([intel-gen4asm], > AC_CONFIG_SRCDIR([Makefile.am]) > AM_INIT_AUTOMAKE([dist-bzip2 foreign]) > > -AM_MAINTAINER_MODE > - > # Checks for programs. > AC_PROG_CC > AM_PROG_LEX > -- > 1.7.7.5 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fri, Jan 11, 2013 at 09:41:05AM +0100, Daniel Vetter wrote: > What about moving gen4asm into a subdir of i-g-t? With git filter-branch > we could even retain the entire history .... > -Daniel I'm not against doing that, it'll shed more light/review/etc on the assembler (I assume patches would have to hit this list first). Xiang, Homer, Gwenole, what do you think of that idea?
On Fri, Jan 11, 2013 at 03:47:16PM +0000, Damien Lespiau wrote: > On Fri, Jan 11, 2013 at 09:41:05AM +0100, Daniel Vetter wrote: > > What about moving gen4asm into a subdir of i-g-t? With git filter-branch > > we could even retain the entire history .... > > -Daniel > > I'm not against doing that, it'll shed more light/review/etc on the > assembler (I assume patches would have to hit this list first). > > Xiang, Homer, Gwenole, what do you think of that idea? Just pushed a assembler branch in my i-g-t repo push a merged intel-gen4asm in the assembler/ directly, keeping all the history. http://cgit.freedesktop.org/~damien/intel-gpu-tools/log/?h=assembler
Hi, > On Fri, Jan 11, 2013 at 09:41:05AM +0100, Daniel Vetter wrote: > > What about moving gen4asm into a subdir of i-g-t? With git > > filter-branch we could even retain the entire history .... > > -Daniel > > I'm not against doing that, it'll shed more light/review/etc on the assembler (I > assume patches would have to hit this list first). > > Xiang, Homer, Gwenole, what do you think of that idea? I think distributions would prefer smaller self-contained projects, that don't need too many dependencies. If we make intel-gen4asm into i-g-t, we'd need additional configure options to enable/disable certain components, e.g. testdisplay with cairo/libudev deps. While we are at re-organizing intel-gen4asm, I would also suggest to think about using Chris' libbrw as the actual backend to the GenX assembler. There is a need to generate code both at run-time and build-time, and it would be better to use the same assembler back-end, so that to simplify validation and enablement of future generations. IMHO, that'd a more sensible move than deciding on where to host intel-gen4asm. :) Thanks, Gwenole.
On Thu, Jan 17, 2013 at 10:56:28AM +0000, Beauchesne, Gwenole wrote: > > On Fri, Jan 11, 2013 at 09:41:05AM +0100, Daniel Vetter wrote: > > I'm not against doing that, it'll shed more light/review/etc on the assembler (I > > assume patches would have to hit this list first). > > > > Xiang, Homer, Gwenole, what do you think of that idea? > > I think distributions would prefer smaller self-contained projects, > that don't need too many dependencies. If we make intel-gen4asm into > i-g-t, we'd need additional configure options to enable/disable > certain components, e.g. testdisplay with cairo/libudev deps. That point seems a bit moot to me, we already need to make some parts of i-g-t optional and the assembler would be one instance of that. I'm also willing to do the work to ensure that's done. > While we are at re-organizing intel-gen4asm, I would also suggest to > think about using Chris' libbrw as the actual backend to the GenX > assembler. There is a need to generate code both at run-time and > build-time, and it would be better to use the same assembler back-end, > so that to simplify validation and enablement of future generations. > IMHO, that'd a more sensible move than deciding on where to host > intel-gen4asm. :) Yes, I agree, and I think having that effort done in i-g-t makes sense as I'd like to chip away at things like a tool to analyse the last batch buffer after a hang for instance. Sharing that code better is definitely what is motivating to look at that. I've started a series to synchronize the brw_*[ch] files with Mesa's but I have to admit I did not look at Chris' libbrw. The changes I have so far are definitely a step towards the right direction though as Chris seems to have started with more recent versions of Mesa's files than the ones we have in the assembler. Hopefully I'll have a first pass done this week. I also had a looks at Chris' libbrw. It does look good but diverges a bit from Mesa now, what I'd love to have is the same thing everywhere, but I guess that's a long shot.
diff --git a/autogen.sh b/autogen.sh index 904cd67..354f254 100755 --- a/autogen.sh +++ b/autogen.sh @@ -9,4 +9,4 @@ cd $srcdir autoreconf -v --install || exit 1 cd $ORIGDIR || exit $? -$srcdir/configure --enable-maintainer-mode "$@" +$srcdir/configure "$@" diff --git a/configure.ac b/configure.ac index 0b4427c..a195505 100644 --- a/configure.ac +++ b/configure.ac @@ -10,8 +10,6 @@ AC_INIT([intel-gen4asm], AC_CONFIG_SRCDIR([Makefile.am]) AM_INIT_AUTOMAKE([dist-bzip2 foreign]) -AM_MAINTAINER_MODE - # Checks for programs. AC_PROG_CC AM_PROG_LEX
This is pretty much deprecated and automake includes a better equivalent when maintainer's mode is not used. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> --- autogen.sh | 2 +- configure.ac | 2 -- 2 files changed, 1 insertions(+), 3 deletions(-)