[RFC]: More robust build sys for UMR

[RFC]: More robust build sys for UMR

[Edward O'Callaghan]

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

[PATCH 1/4] cmake_modules: Add libpciaccess finder

[Edward O'Callaghan]

Signed-off-by: Edward O'Callaghan <funfunctor@folklore1984.net>
---
 cmake_modules/FindPCIAccess.cmake | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 cmake_modules/FindPCIAccess.cmake

diff --git a/cmake_modules/FindPCIAccess.cmake b/cmake_modules/FindPCIAccess.cmake
new file mode 100644
index 0000000..09ddd51
--- /dev/null
+++ b/cmake_modules/FindPCIAccess.cmake
@@ -0,0 +1,35 @@
+# Try to find pciaccess
+#
+# Once done, this will define
+#
+# PCIACCESS_FOUND
+# PCIACCESS_INCLUDE_DIR
+# PCIACCESS_LIBRARIES
+
+find_package(PkgConfig)
+
+pkg_check_modules(PC_PCIACCESS QUIET pciaccess)
+
+find_path(PCIACCESS_INCLUDE_DIR NAMES pciaccess.h
+    HINTS
+    ${PC_PCIACCESS_INCLUDEDIR}
+    ${PC_PCIACCESS_INCLUDE_DIRS}
+    /usr/include
+)
+
+find_library(PCIACCESS_LIBRARY NAMES pciaccess
+    HINTS
+    ${PC_PCIACCESS_LIBDIR}
+    ${PC_PCIACCESS_LIBRARY_DIRS}
+    /usr/lib64
+    /usr/lib
+)
+
+SET(PCIACCESS_LIBRARIES optimized ${PCIACCESS_LIBRARY})
+
+include(FindPackageHandleStandardArgs)
+find_package_handle_standard_args(PCIACCESS DEFAULT_MSG
+	PCIACCESS_LIBRARIES PCIACCESS_INCLUDE_DIR
+)
+
+mark_as_advanced(PCIACCESS_INCLUDE_DIR PCIACCESS_LIBRARIES)
-- 
2.9.3

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 2/4] cmake: Initial build system

[Edward O'Callaghan]

V.2: squash in,
  cmake: Add docs manpage build target
  cmake: Add install targets
  cmake: Misc fixes

Signed-off-by: Edward O'Callaghan <funfunctor@folklore1984.net>
---
 CMakeLists.txt              | 40 ++++++++++++++++++++++++++++++++++++++++
 doc/CMakeLists.txt          |  3 +++
 src/CMakeLists.txt          |  6 ++++++
 src/app/CMakeLists.txt      | 24 ++++++++++++++++++++++++
 src/lib/CMakeLists.txt      | 28 ++++++++++++++++++++++++++++
 src/lib/asic/CMakeLists.txt | 20 ++++++++++++++++++++
 src/lib/ip/CMakeLists.txt   | 41 +++++++++++++++++++++++++++++++++++++++++
 7 files changed, 162 insertions(+)
 create mode 100644 CMakeLists.txt
 create mode 100644 doc/CMakeLists.txt
 create mode 100644 src/CMakeLists.txt
 create mode 100644 src/app/CMakeLists.txt
 create mode 100644 src/lib/CMakeLists.txt
 create mode 100644 src/lib/asic/CMakeLists.txt
 create mode 100644 src/lib/ip/CMakeLists.txt

diff --git a/CMakeLists.txt b/CMakeLists.txt
new file mode 100644
index 0000000..bef94fd
--- /dev/null
+++ b/CMakeLists.txt
@@ -0,0 +1,40 @@
+# Copyright 2017 Edward O'Callaghan <funfunctor@folklore1984.net>
+
+cmake_minimum_required(VERSION 3.0.1)
+
+project(umr)
+
+SET(MAJOR_VERSION 1)
+SET(MINOR_VERSION 0)
+
+SET(RELEASE_VERSION \"${MAJOR_VERSION}.${MINOR_VERSION}\")
+execute_process(COMMAND  git describe --abbrev=12 --always
+    WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
+    OUTPUT_STRIP_TRAILING_WHITESPACE
+    OUTPUT_VARIABLE GIT_REV
+)
+add_definitions(-DUMR_BUILD_VER=${RELEASE_VERSION})
+add_definitions(-DUMR_BUILD_REV=\"${GIT_REV}\")
+
+# Add local repository for FindXXX.cmake modules.
+SET(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake_modules/" ${CMAKE_MODULE_PATH})
+
+find_package(Curses REQUIRED)
+include_directories(${CURSES_INCLUDE_DIRS})
+
+find_package(PCIAccess REQUIRED)
+include_directories(${PCIACCESS_INCLUDE_DIR})
+
+set(REQUIRED_EXTERNAL_LIBS
+  ${CURSES_LIBRARIES}
+  ${PCIACCESS_LIBRARIES}
+)
+
+# Global setting: build everything position independent
+set(CMAKE_POSITION_INDEPENDENT_CODE ON)
+
+# CFLAGS += -Wall -W -O2 -g3 -Isrc/ -DPIC -fPIC
+set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -W -O2 -g3")
+
+add_subdirectory(src)
+add_subdirectory(doc)
diff --git a/doc/CMakeLists.txt b/doc/CMakeLists.txt
new file mode 100644
index 0000000..112ad48
--- /dev/null
+++ b/doc/CMakeLists.txt
@@ -0,0 +1,3 @@
+# Copyright 2017 Edward O'Callaghan <funfunctor@folklore1984.net>
+
+install(FILES umr.1 DESTINATION ${CMAKE_INSTALL_PREFIX}/man/man1)
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
new file mode 100644
index 0000000..e9eaeeb
--- /dev/null
+++ b/src/CMakeLists.txt
@@ -0,0 +1,6 @@
+# Copyright 2017 Edward O'Callaghan <funfunctor@folklore1984.net>
+
+include_directories(${CMAKE_CURRENT_SOURCE_DIR}/)
+
+add_subdirectory(lib)
+add_subdirectory(app)
diff --git a/src/app/CMakeLists.txt b/src/app/CMakeLists.txt
new file mode 100644
index 0000000..117d3f1
--- /dev/null
+++ b/src/app/CMakeLists.txt
@@ -0,0 +1,24 @@
+# Copyright 2017 Edward O'Callaghan <funfunctor@folklore1984.net>
+
+project(umr)
+
+#application objects
+add_library(umrapp
+  print.c
+  print_config.c
+  ring_read.c
+  scan.c
+  scan_log.c
+  top.c
+  umr_lookup.c
+  set_bit.c
+  set_reg.c
+  print_waves.c
+  enum.c
+)
+
+add_executable(umr main.c)
+target_link_libraries(umr umrapp)
+target_link_libraries(umr umrcore)
+
+install(TARGETS umr DESTINATION bin)
diff --git a/src/lib/CMakeLists.txt b/src/lib/CMakeLists.txt
new file mode 100644
index 0000000..46c75d6
--- /dev/null
+++ b/src/lib/CMakeLists.txt
@@ -0,0 +1,28 @@
+# Copyright 2017 Edward O'Callaghan <funfunctor@folklore1984.net>
+
+add_subdirectory(asic)
+add_subdirectory(ip)
+
+add_library(umrcore STATIC
+  bitfield_print.c
+  close_asic.c
+  create_asic_helper.c
+  discover_by_did.c
+  discover_by_name.c
+  discover.c
+  dump_ib.c
+  find_reg.c
+  mmio.c
+  query_drm.c
+  read_sgpr.c
+  read_vram.c
+  ring_decode.c
+  scan_config.c
+  wave_status.c
+  create_mmio_accel.c
+  $<TARGET_OBJECTS:asic> $<TARGET_OBJECTS:ip>
+)
+
+target_link_libraries(umrcore ${REQUIRED_EXTERNAL_LIBS})
+
+install(TARGETS umrcore DESTINATION lib)
diff --git a/src/lib/asic/CMakeLists.txt b/src/lib/asic/CMakeLists.txt
new file mode 100644
index 0000000..6cfec30
--- /dev/null
+++ b/src/lib/asic/CMakeLists.txt
@@ -0,0 +1,20 @@
+# Copyright 2017 Edward O'Callaghan <funfunctor@folklore1984.net>
+
+#library objects (ASICs blocks)
+add_library(asic OBJECT
+  bonaire.c
+  carrizo.c
+  fiji.c
+  hainan.c
+  kaveri.c
+  oland.c
+  pitcairn.c
+  polaris10.c
+  polaris11.c
+  polaris12.c
+  stoney.c
+  tahiti.c
+  tonga.c
+  topaz.c
+  verde.c
+)
diff --git a/src/lib/ip/CMakeLists.txt b/src/lib/ip/CMakeLists.txt
new file mode 100644
index 0000000..2c2fe68
--- /dev/null
+++ b/src/lib/ip/CMakeLists.txt
@@ -0,0 +1,41 @@
+# Copyright 2017 Edward O'Callaghan <funfunctor@folklore1984.net>
+
+add_library(ip OBJECT
+  bif30.c
+  bif41.c
+  bif50.c
+  bif51.c
+  dce100.c
+  dce110.c
+  dce112.c
+  dce60.c
+  dce80.c
+  gfx60.c
+  gfx70.c
+  gfx72.c
+  gfx80.c
+  gfx81.c
+  gmc60.c
+  gmc70.c
+  gmc71.c
+  gmc81.c
+  gmc82.c
+  oss10.c
+  oss20.c
+  oss30.c
+  smu60.c
+  smu700.c
+  smu701.c
+  smu710.c
+  smu711.c
+  smu712.c
+  smu713.c
+  smu80.c
+  uvd40.c
+  uvd42.c
+  uvd5.c
+  uvd6.c
+  vce1.c
+  vce2.c
+  vce3.c
+)
-- 
2.9.3

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 3/4] README: minor update for cmake buildsys

[Edward O'Callaghan]

Signed-off-by: Edward O'Callaghan <funfunctor@folklore1984.net>
---
 README | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README b/README
index 2700736..7d8b025 100644
--- a/README
+++ b/README
@@ -32,6 +32,7 @@ To build umr you will need pciaccess and ncurses headers and libraries.
 Which are available in both Fedora and Ubuntu (as well as other
 distributions).  To build simply invoke the make command
 
+    $ mkdir build && cd build/ && cmake ../
     $ make
 
 and then
-- 
2.9.3

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 4/4] drop orginal Makefile && stub bin/ directory

[Edward O'Callaghan]

Signed-off-by: Edward O'Callaghan <funfunctor@folklore1984.net>
---
 Makefile  | 80 ---------------------------------------------------------------
 bin/.keep |  0
 2 files changed, 80 deletions(-)
 delete mode 100644 Makefile
 delete mode 100644 bin/.keep

diff --git a/Makefile b/Makefile
deleted file mode 100644
index 5c47832..0000000
--- a/Makefile
+++ /dev/null
@@ -1,80 +0,0 @@
-LIBNAME=bin/libumr.a
-BINNAME=bin/umr
-
-CFLAGS += -Wall -W -O2 -g3 -Isrc/ -DPIC -fPIC
-
-REV=$(shell git rev-parse HEAD | cut -b1-12)
-VER_MAJOR=1
-VER_MINOR=0
-CFLAGS+=-DUMR_BUILD_REV=\"${REV}\" -DUMR_BUILD_VER=\"${VER_MAJOR}.${VER_MINOR}\"
-
-
-PREFIX ?= /usr/local/
-
-#library objects (ASICs blocks)
-LIBOBJS=\
-src/lib/asic/bonaire.o src/lib/asic/carrizo.o src/lib/asic/fiji.o \
-src/lib/asic/hainan.o src/lib/asic/kaveri.o src/lib/asic/oland.o \
-src/lib/asic/pitcairn.o src/lib/asic/polaris10.o src/lib/asic/polaris11.o \
-src/lib/asic/polaris12.o src/lib/asic/stoney.o src/lib/asic/tahiti.o \
-src/lib/asic/tonga.o src/lib/asic/topaz.o src/lib/asic/verde.o \
-\
-src/lib/bitfield_print.o src/lib/close_asic.o src/lib/create_asic_helper.o \
-src/lib/discover_by_did.o src/lib/discover_by_name.o src/lib/discover.o src/lib/dump_ib.o \
-src/lib/find_reg.o src/lib/mmio.o src/lib/query_drm.o \
-src/lib/read_sgpr.o src/lib/read_vram.o src/lib/ring_decode.o src/lib/scan_config.o \
-src/lib/wave_status.o src/lib/create_mmio_accel.o \
-\
-src/lib/ip/bif30.o src/lib/ip/bif41.o src/lib/ip/bif50.o src/lib/ip/bif51.o \
-\
-src/lib/ip/dce100.o src/lib/ip/dce110.o src/lib/ip/dce112.o src/lib/ip/dce60.o \
-src/lib/ip/dce80.o \
-\
-src/lib/ip/gfx60.o src/lib/ip/gfx70.o src/lib/ip/gfx72.o src/lib/ip/gfx80.o \
-src/lib/ip/gfx81.o \
-\
-src/lib/ip/gmc60.o src/lib/ip/gmc70.o src/lib/ip/gmc71.o src/lib/ip/gmc81.o \
-src/lib/ip/gmc82.o \
-\
-src/lib/ip/oss10.o src/lib/ip/oss20.o src/lib/ip/oss30.o \
-\
-src/lib/ip/smu60.o src/lib/ip/smu700.o src/lib/ip/smu701.o src/lib/ip/smu710.o \
-src/lib/ip/smu711.o src/lib/ip/smu712.o src/lib/ip/smu713.o src/lib/ip/smu80.o \
-\
-src/lib/ip/uvd40.o src/lib/ip/uvd42.o src/lib/ip/uvd5.o src/lib/ip/uvd6.o \
-\
-src/lib/ip/vce1.o src/lib/ip/vce2.o src/lib/ip/vce3.o
-
-
-#application objects
-APPOBJS=src/app/main.o src/app/print.o src/app/print_config.o \
-src/app/ring_read.o src/app/scan.o src/app/scan_log.o \
-src/app/top.o src/app/umr_lookup.o src/app/set_bit.o src/app/set_reg.o src/app/print_waves.o \
-src/app/enum.o
-
-${BINNAME}: ${LIBNAME} ${APPOBJS}
-	${CC} ${CFLAGS} ${APPOBJS} ${LIBNAME} -lpciaccess -lncurses -o $@
-
-${LIBOBJS}: src/umr.h
-${APPOBJS}: src/umr.h
-
-${LIBNAME}: ${LIBOBJS}
-	${AR} ${ARFLAGS} $@ $^
-
-.PHONY: install
-install: bin/umr
-	mkdir -p ${PREFIX}/bin
-	mkdir -p ${PREFIX}/share/man/man1
-	install ${BINNAME} ${PREFIX}/bin/
-	install doc/umr.1 ${PREFIX}/share/man/man1/
-
-.PHONY: installlib
-installlib: ${LIBOBJS}
-	mkdir -p ${PREFIX}/include
-	mkdir -p ${PREFIX}/lib
-	install src/*.h ${PREFIX}/include/
-	install ${LIBNAME} ${PREFIX}/lib/
-
-.PHONY: clean
-clean:
-	rm -f bin/umr ${LIBNAME} ${LIBOBJS} ${APPOBJS}
diff --git a/bin/.keep b/bin/.keep
deleted file mode 100644
index e69de29..0000000
-- 
2.9.3

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC]: More robust build sys for UMR

[StDenis, Tom]

[-- Attachment #1.1.1: Type: text/plain, Size: 1494 bytes --]

Hi Edward,


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 "make" as opposed to "mkdir build && cd build && cmake .. && make".


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.

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?

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

Thanks,
Tom

________________________________
From: Edward O'Callaghan <funfunctor@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

[-- Attachment #1.1.2: Type: text/html, Size: 2633 bytes --]

[-- Attachment #1.2: OutlookEmoji-😊.png --]
[-- Type: image/png, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC]: More robust build sys for UMR

[Bas Nieuwenhuizen]

[-- Attachment #1.1: Type: text/plain, Size: 2712 bytes --]

Hi,



I think the current build system is a bit too naive though. On my distro
archlinux the libdrm headers are installed in /usr/include/libdrm, which
causes the include to drm/drm.h in src/lib/query_drm.c to fail.


So if it is in /usr/include/drm on Ubuntu, we are going to need some
autodetection to find the right include path. Autotools definitely
sounds like overkill to me, and the current build system is pretty
simple indeed, but needing to change the source isn't ideal.


By the way, I don't think the current make system handles dependencies
on headers correctly? e.g. if I modify umrapp.h, make rebuilds nothing.
This is one of the things cmake gives you for free, though with a bit of
work make can do it too.


Yours sincerely,

Bas Nieuwenhuizen





On Sun, Feb 5, 2017, at 12:42, StDenis, Tom wrote:

> Hi Edward,



> 



> 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
> "make" as opposed to "mkdir build && cd build && cmake .. && make".
> 



> 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.
> 

> 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?
> 

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

> 

> 

> Thanks,

> Tom

> 

> 

> 

> *From:* Edward O'Callaghan <funfunctor-dczkZgxz+BNUPWh3PAxdjQ@public.gmane.org> *Sent:*
> Saturday, February 4, 2017 23:59 *To:* amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.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-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org

> https://lists.freedesktop.org/mailman/listinfo/amd-gfx



[-- Attachment #1.2.1: Type: text/html, Size: 4575 bytes --]

[-- Attachment #1.2.2: OutlookEmoji-😊.png --]
[-- Type: image/png, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC]: More robust build sys for UMR

[Edward O'Callaghan]

[-- Attachment #1.1.1: Type: text/plain, Size: 3040 bytes --]



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-dczkZgxz+BNUPWh3PAxdjQ@public.gmane.org>
> *Sent:* Saturday, February 4, 2017 23:59
> *To:* amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC]: More robust build sys for UMR

[StDenis, Tom]

[-- Attachment #1.1.1: Type: text/plain, Size: 4016 bytes --]

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@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 <funfunctor@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


[-- Attachment #1.1.2: Type: text/html, Size: 5604 bytes --]

[-- Attachment #1.2: OutlookEmoji-😊.png --]
[-- Type: image/png, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC]: More robust build sys for UMR

[StDenis, Tom]

[-- Attachment #1.1.1: Type: text/plain, Size: 2923 bytes --]

Hi Bas,


What would be a good way to work around the paths though? Is there a pkg config for libdrm?

Thanks,
Tom
________________________________
From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> on behalf of Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Sent: Sunday, February 5, 2017 08:12
To: amd-gfx@lists.freedesktop.org
Subject: Re: [RFC]: More robust build sys for UMR

Hi,

I think the current build system is a bit too naive though. On my distro archlinux the libdrm headers are installed in /usr/include/libdrm, which causes the include to drm/drm.h in src/lib/query_drm.c to fail.

So if it is in /usr/include/drm on Ubuntu, we are going to need some autodetection to find the right include path. Autotools definitely sounds like overkill to me, and the current build system is pretty simple indeed, but needing to change the source isn't ideal.

By the way, I don't think the current make system handles dependencies on headers correctly? e.g. if I modify umrapp.h, make rebuilds nothing.  This is one of the things cmake gives you for free, though with a bit of work make can do it too.

Yours sincerely,
Bas Nieuwenhuizen


On Sun, Feb 5, 2017, at 12:42, StDenis, Tom wrote:

Hi Edward,


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 "make" as opposed to "mkdir build && cd build && cmake .. && make".


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.

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?

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


Thanks,
Tom


________________________________

From: Edward O'Callaghan <funfunctor@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<mailto:amd-gfx@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[-- Attachment #1.1.2: Type: text/html, Size: 5765 bytes --]

[-- Attachment #1.2: OutlookEmoji-😊.png --]
[-- Type: image/png, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC]: More robust build sys for UMR

[StDenis, Tom]

[-- Attachment #1.1.1: Type: text/plain, Size: 3419 bytes --]

Hi all,


Never mind answered my own question:


$ pkg-config libdrm --cflags
-I/usr/include/libdrm

So we could in theory include "drm.h" and then just add that to the head of our CFLAGS.

Tom



________________________________
From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> on behalf of StDenis, Tom <Tom.StDenis@amd.com>
Sent: Sunday, February 5, 2017 09:55
To: Bas Nieuwenhuizen; amd-gfx@lists.freedesktop.org
Subject: Re: [RFC]: More robust build sys for UMR


Hi Bas,


What would be a good way to work around the paths though? Is there a pkg config for libdrm?

Thanks,
Tom
________________________________
From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> on behalf of Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Sent: Sunday, February 5, 2017 08:12
To: amd-gfx@lists.freedesktop.org
Subject: Re: [RFC]: More robust build sys for UMR

Hi,

I think the current build system is a bit too naive though. On my distro archlinux the libdrm headers are installed in /usr/include/libdrm, which causes the include to drm/drm.h in src/lib/query_drm.c to fail.

So if it is in /usr/include/drm on Ubuntu, we are going to need some autodetection to find the right include path. Autotools definitely sounds like overkill to me, and the current build system is pretty simple indeed, but needing to change the source isn't ideal.

By the way, I don't think the current make system handles dependencies on headers correctly? e.g. if I modify umrapp.h, make rebuilds nothing.  This is one of the things cmake gives you for free, though with a bit of work make can do it too.

Yours sincerely,
Bas Nieuwenhuizen


On Sun, Feb 5, 2017, at 12:42, StDenis, Tom wrote:

Hi Edward,


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 "make" as opposed to "mkdir build && cd build && cmake .. && make".


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.

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?

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


Thanks,
Tom


________________________________

From: Edward O'Callaghan <funfunctor@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<mailto:amd-gfx@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[-- Attachment #1.1.2: Type: text/html, Size: 6817 bytes --]

[-- Attachment #1.2: OutlookEmoji-😊.png --]
[-- Type: image/png, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC]: More robust build sys for UMR

[Andres Rodriguez]

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@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 <funfunctor@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

Re: [RFC]: More robust build sys for UMR

[StDenis, Tom]

[-- Attachment #1.1: Type: text/plain, Size: 6784 bytes --]

Hi Andres,


Thanks for the feedback.  I've decided to push Edward's patches to master since it's in the projects best interest to minimize build/package friction going forward.


Of course now I have to rebase our NPI branches internally since they're based on the older makefile ...  That's more of an AMD problem though.


If someone could review my patch that detects the libdrm path I'd like to get that in sooner than later so the package is more buildable by time people get to work on Monday :-)


Tom


________________________________
From: Andres Rodriguez <andresx7@gmail.com>
Sent: Sunday, February 5, 2017 11:11
To: StDenis, Tom; Edward O'Callaghan; amd-gfx@lists.freedesktop.org
Subject: Re: [RFC]: More robust build sys for UMR

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@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 <funfunctor@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 Info Page - lists.freedesktop.org<https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx Archives. Using amd-gfx: To post a message to all the list members, send email ...



>

[-- Attachment #1.2: Type: text/html, Size: 11037 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC]: More robust build sys for UMR

[Michel Dänzer]

On 06/02/17 12:16 AM, StDenis, Tom wrote:
> 
> $ pkg-config libdrm --cflags
> -I/usr/include/libdrm
> 
> So we could in theory include "drm.h" and then just add that to the head
> of our CFLAGS.

Make that <drm.h>, but yes, that's the correct way, not just in theory. :)


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx