<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif;" dir="ltr">
<p>Hi Edward,</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>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
<img class="EmojiInsert" id="OWAEmoji126245" alt="😊" style="vertical-align: bottom;" src="cid:7b1cf561-12a0-424d-977f-213ca76ba3da"></p>
<p><br>
</p>
<p>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.
  </p>
<p><br>
</p>
<p>Tom</p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Edward O'Callaghan <funfunctor@folklore1984.net><br>
<b>Sent:</b> Sunday, February 5, 2017 08:29<br>
<b>To:</b> StDenis, Tom; amd-gfx@lists.freedesktop.org<br>
<b>Subject:</b> Re: [RFC]: More robust build sys for UMR</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
<br>
On 02/05/2017 10:42 PM, StDenis, Tom wrote:<br>
> Hi Edward,<br>
<br>
Hey Tom,<br>
<br>
> <br>
> <br>
> Well the patches apply and work but I'm not really sure what problem<br>
> it's meant to solve ðŸ˜Š.  Building previously was actually simpler with<br>
<br>
So the idea here was to implement something a little more robust and<br>
extensible. For example with a couple of extra lines cmake can produce<br>
rpm's, deb's and tar's too as build by-products. I can add this<br>
functionality if you wish? Additionally another couple of lines a unit<br>
tests could be hooked in if that is useful?<br>
<br>
Fundamentally the idea was to have a "proper" build system that can<br>
be extensible enough not to get in the way while the community<br>
elaborates on UMR some more with additional features. I was thinking<br>
about looking at unifying other peoples radeon debug/re tooling together<br>
into UMR to be the one-stop tool as my Sunday afternoon weekend project<br>
you see :) .<br>
<br>
> "make" as opposed to "mkdir build && cd build && cmake .. && make".<br>
><br>
<br>
I just added that step because its nice to build out of tree, you don't<br>
have to.<br>
<br>
> <br>
> On a BSD system (where this wouldn't really work without the<br>
> corresponding debugfs entries) gmake could be used to build it provided<br>
> ncurses/pciaccess were around.<br>
<br>
Well in truth I didn't test on the BSD's yet, however it helps give some<br>
a good foundation so they could port it should they wish. I am assuming<br>
so since they seem to be updating their graphics stack these days.<br>
<br>
> <br>
> <br>
> If this legitimately makes it more stable to build on Linux systems then<br>
> I'm all for it.  Can anyone elaborate on where the simple make system<br>
> would fail?<br>
<br>
Well I hope so, that's why I RFC it. I expect this to work out the box<br>
on all distributions right off the bat and I would be interested in<br>
feedback for that.<br>
<br>
> <br>
> (I'm not saying NAK I'm simply asking for my own edification).<br>
<br>
Sure sure, this only took me a hour to put together because of _my_ itch<br>
so don't stress.<br>
<br>
> <br>
> Thanks,<br>
> Tom<br>
<br>
Kind Regards,<br>
Edward.<br>
<br>
> <br>
> ------------------------------------------------------------------------<br>
> *From:* Edward O'Callaghan <funfunctor@folklore1984.net><br>
> *Sent:* Saturday, February 4, 2017 23:59<br>
> *To:* amd-gfx@lists.freedesktop.org<br>
> *Cc:* StDenis, Tom<br>
> *Subject:* [RFC]: More robust build sys for UMR<br>
>  <br>
> Keeping with the tradition of changing the build system on initial<br>
> release, here we go again.. This follow series introduces the cmake<br>
> build system that is intended to be a little more robust across<br>
> various distros and presumably the BSD's also. The installation<br>
> prefix is configurable in the usual cmake way:<br>
>  `cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..`<br>
> <br>
> Please kindly review,<br>
> <br>
> Edward O'Callaghan (4):<br>
>  [PATCH 1/4] cmake_modules: Add libpciaccess finder<br>
>  [PATCH 2/4] cmake: Initial build system<br>
>  [PATCH 3/4] README: minor update for cmake buildsys<br>
>  [PATCH 4/4] drop orginal Makefile && stub bin/ directory<br>
<br>
</div>
</span></font></div>
</div>
</body>
</html>