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 <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
>
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
