[RFC]: More robust build sys for UMR

[StDenis, Tom]

Hi Edward,


Sounds good to me.  I'm sure our build-team folks would actually be in favour of something that could help make deb/rpm packages.


I typically only run Fedora and Ubuntu so if others who run Arch/Gentoo/SUSE/etc want to weigh in that'd be appreciated.  If nobody raises any objections I'll RB your series and push them to master sometime tomorrow.


By all means if you want to add other debug features go for it.  Keep in mind it already captures features from things like radeontop and setreg type tools [😊]


One of the open issues right now is the VM decoding in the read_vram() functionality (specifically when using follow_ib).  It's hard to instrument a test of that since VM addresses are live and ever chaotic but I've yet to see a successful IB read back.


Tom


________________________________
From: Edward O'Callaghan <funfunctor at folklore1984.net>
Sent: Sunday, February 5, 2017 08:29
To: StDenis, Tom; amd-gfx at lists.freedesktop.org
Subject: Re: [RFC]: More robust build sys for UMR



On 02/05/2017 10:42 PM, StDenis, Tom wrote:
> Hi Edward,

Hey Tom,

>
>
> Well the patches apply and work but I'm not really sure what problem
> it's meant to solve 😊.  Building previously was actually simpler with

So the idea here was to implement something a little more robust and
extensible. For example with a couple of extra lines cmake can produce
rpm's, deb's and tar's too as build by-products. I can add this
functionality if you wish? Additionally another couple of lines a unit
tests could be hooked in if that is useful?

Fundamentally the idea was to have a "proper" build system that can
be extensible enough not to get in the way while the community
elaborates on UMR some more with additional features. I was thinking
about looking at unifying other peoples radeon debug/re tooling together
into UMR to be the one-stop tool as my Sunday afternoon weekend project
you see :) .

> "make" as opposed to "mkdir build && cd build && cmake .. && make".
>

I just added that step because its nice to build out of tree, you don't
have to.

>
> On a BSD system (where this wouldn't really work without the
> corresponding debugfs entries) gmake could be used to build it provided
> ncurses/pciaccess were around.

Well in truth I didn't test on the BSD's yet, however it helps give some
a good foundation so they could port it should they wish. I am assuming
so since they seem to be updating their graphics stack these days.

>
>
> If this legitimately makes it more stable to build on Linux systems then
> I'm all for it.  Can anyone elaborate on where the simple make system
> would fail?

Well I hope so, that's why I RFC it. I expect this to work out the box
on all distributions right off the bat and I would be interested in
feedback for that.

>
> (I'm not saying NAK I'm simply asking for my own edification).

Sure sure, this only took me a hour to put together because of _my_ itch
so don't stress.

>
> Thanks,
> Tom

Kind Regards,
Edward.

>
> ------------------------------------------------------------------------
> *From:* Edward O'Callaghan <funfunctor at folklore1984.net>
> *Sent:* Saturday, February 4, 2017 23:59
> *To:* amd-gfx at lists.freedesktop.org
> *Cc:* StDenis, Tom
> *Subject:* [RFC]: More robust build sys for UMR
>
> Keeping with the tradition of changing the build system on initial
> release, here we go again.. This follow series introduces the cmake
> build system that is intended to be a little more robust across
> various distros and presumably the BSD's also. The installation
> prefix is configurable in the usual cmake way:
>  `cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..`
>
> Please kindly review,
>
> Edward O'Callaghan (4):
>  [PATCH 1/4] cmake_modules: Add libpciaccess finder
>  [PATCH 2/4] cmake: Initial build system
>  [PATCH 3/4] README: minor update for cmake buildsys
>  [PATCH 4/4] drop orginal Makefile && stub bin/ directory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20170205/e5fc67fa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OutlookEmoji-😊.png
Type: image/png
Size: 488 bytes
Desc: OutlookEmoji-😊.png
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20170205/e5fc67fa/attachment-0001.png>