Hey Tom,
It's great to see umr make it to the public. I've given it a quick spin
and it is pretty awesome, although I don't have much time this weekend
to play with it.
Wanted to weigh in my 2c regarding cmake.
Some of the things I like about cmake:
* Compatible with out of tree builds by default
- Super simple *guaranteed* make clean equivalent with rm -f build/
- Simple gitignore files
- Both of these reasons result in sidestepping some common and very
annoying bugs in makefiles
* Easy packaging for release with cpack
* Removes a lot of the boilerplate (specially for libraries)
* Good compatibility across distros
- Without a lot of the "horrible" things from automake
* There is a good community around cmake that has some cool modules
available for it
Some of the things I don't like about cmake:
* The syntax is horrible
* I think ctest is overly complicated compared to other frameworks like
gtest.
- Doing basic things like attaching a debugger are not
straightforward
Weighing the above I tend to side on pro-cmake.
Again, thanks for the work on the great tool. I might have a bit more
feedback once I start using it more heavily next week.
Regards,
Andres
On 2/5/2017 9:52 AM, StDenis, Tom wrote:
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 <funfunc...@folklore1984.net>
*Sent:* Sunday, February 5, 2017 08:29
*To:* StDenis, Tom; amd-gfx@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 <funfunc...@folklore1984.net>
*Sent:* Saturday, February 4, 2017 23:59
*To:* amd-gfx@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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
