* [PATCH ipmi-fru-parser] RFC: use cmake. (DO NOT MERGE)
@ 2016-03-03 22:30 OpenBMC Patches
2016-03-03 22:30 ` [PATCH ipmi-fru-parser] RFC: use cmake OpenBMC Patches
0 siblings, 1 reply; 6+ messages in thread
From: OpenBMC Patches @ 2016-03-03 22:30 UTC (permalink / raw)
To: openbmc
There was a previous proposal to consider autotools (see
openbmc/ipmi-fru-parser#7). This is an alternative implementation
using cmake.
https://github.com/openbmc/ipmi-fru-parser/pull/11
Patrick Williams (1):
RFC: use cmake.
.gitignore | 12 +++++++++
CMakeLists.txt | 30 ++++++++++++++++++++++
Makefile | 75 -------------------------------------------------------
cmake/sdbus.cmake | 16 ++++++++++++
4 files changed, 58 insertions(+), 75 deletions(-)
create mode 100644 .gitignore
create mode 100644 CMakeLists.txt
delete mode 100644 Makefile
create mode 100644 cmake/sdbus.cmake
--
2.7.1
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH ipmi-fru-parser] RFC: use cmake.
2016-03-03 22:30 [PATCH ipmi-fru-parser] RFC: use cmake. (DO NOT MERGE) OpenBMC Patches
@ 2016-03-03 22:30 ` OpenBMC Patches
2016-03-07 4:00 ` Joel Stanley
0 siblings, 1 reply; 6+ messages in thread
From: OpenBMC Patches @ 2016-03-03 22:30 UTC (permalink / raw)
To: openbmc
From: Patrick Williams <patrick@stwcx.xyz>
There was a previous proposal to consider autotools (see
openbmc/ipmi-fru-parser#7). This is an alternative implementation
using cmake.
---
.gitignore | 12 +++++++++
CMakeLists.txt | 30 ++++++++++++++++++++++
Makefile | 75 -------------------------------------------------------
cmake/sdbus.cmake | 16 ++++++++++++
4 files changed, 58 insertions(+), 75 deletions(-)
create mode 100644 .gitignore
create mode 100644 CMakeLists.txt
delete mode 100644 Makefile
create mode 100644 cmake/sdbus.cmake
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..727471a
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,12 @@
+#### vi files ####
+*.swp
+#### --- vi --- ####
+
+#### CMAKE Files ####
+CMakeCache.txt
+CMakeFiles
+CMakeScripts
+Makefile
+cmake_install.cmake
+install_manifest.txt
+#### --- CMAKE --- ####
diff --git a/CMakeLists.txt b/CMakeLists.txt
new file mode 100644
index 0000000..0a00985
--- /dev/null
+++ b/CMakeLists.txt
@@ -0,0 +1,30 @@
+cmake_minimum_required(VERSION 3.1)
+project(ipmi-fru-parser)
+
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")
+set(CMAKE_CXX_STANDARD 14)
+set(CMAKE_CXX_STANDARD_REQUIRED on)
+
+include("cmake/sdbus.cmake")
+
+add_library(writefrudata SHARED
+ frup.c
+ writefrudata.C
+)
+target_link_libraries(writefrudata ${SYSTEMD_LIBRARY})
+install(TARGETS writefrudata LIBRARY DESTINATION lib/host-ipmid)
+
+add_library(strgfnhandler SHARED
+ strgfnhandler.C
+)
+target_link_libraries(strgfnhandler writefrudata)
+install(TARGETS strgfnhandler LIBRARY DESTINATION lib)
+
+add_executable(phosphor-read-eeprom
+ argument.C
+ readeeprom.C
+)
+target_link_libraries(phosphor-read-eeprom writefrudata)
+target_link_libraries(phosphor-read-eeprom ${SYSTEMD_LIBRARY})
+
+install(TARGETS phosphor-read-eeprom RUNTIME DESTINATION bin)
diff --git a/Makefile b/Makefile
deleted file mode 100644
index dc66a77..0000000
--- a/Makefile
+++ /dev/null
@@ -1,75 +0,0 @@
-LIBS += libwritefrudata.so
-HOST_LIBS += libstrgfnhandler.so
-libwritefrudata.so_OBJS += frup.o writefrudata.o
-libstrgfnhandler.so_OBJS += strgfnhandler.o
-
-EXES += phosphor-read-eeprom
-
-phosphor-read-eeprom_OBJS += readeeprom.o argument.o
-phosphor-read-eeprom_EXTRA_LIBS += writefrudata
-libstrgfnhandler.so_EXTRA_LIBS += writefrudata
-libwritefrudata.so_NEEDED += libsystemd
-phosphor-read-eeprom_NEEDED += libsystemd
-
-#### -----------------------------------------------------------------------####
-# #
-## Compilare Regulas Sequi ##
-# #
-#### -----------------------------------------------------------------------####
-OPTFLAGS ?= -O3 -g -pipe -G -K
-CFLAGS ?= $(OPTFLAGS)
-CXXFLAGS ?= $(OPTFLAGS)
-CFLAGS += -Wall -flto -fPIC
-CXXFLAGS += --std=gnu++14 -Wall -flto -fPIC
-
-__PKG_CONFIG = $(if $1,$(shell pkg-config $2 $1))
-__EXTRA_LIB_RESOLV = $(if $1,$1)
-
-define __BUILD_EXE
-$1 : $$($1_OBJS) | $$(LIBS) $$(HOST_LIBS)
- $$(LINK.cpp) -o $$@ $$^ $(call __EXTRA_LIB_RESOLV,$(addprefix -l,$($1_EXTRA_LIBS))) -L. $(call __PKG_CONFIG,$($1_NEEDED),--libs)
-
-$(eval CXXFLAGS += $(call __PKG_CONFIG,$($1_NEEDED),--cflags))
-
-#include $$($1_OBJS:.o=.d)
-endef
-
-$(foreach exe,$(EXES),$(eval $(call __BUILD_EXE,$(exe))))
-
-define __BUILD_LIB
-$1 : $$($1_OBJS) | $$(addsuffix .so,$$(addprefix lib,$$($1_EXTRA_LIBS)))
- $$(LINK.cpp) -fPIC -shared -o $$@ $$^ $(call __EXTRA_LIB_RESOLV,$(addprefix -l,$($1_EXTRA_LIBS))) -L. $(call __PKG_CONFIG,$($1_NEEDED),--libs)
-
-$(eval CXXFLAGS += $(call __PKG_CONFIG,$($1_NEEDED),--cflags))
-
-#include $$($1_OBJS:.o=.d)
-endef
-
-$(foreach lib,$(LIBS),$(eval $(call __BUILD_LIB,$(lib))))
-$(foreach lib,$(HOST_LIBS),$(eval $(call __BUILD_LIB,$(lib))))
-
-.PHONY: clean
-clean:
- $(RM) $(foreach exe,$(EXES),$(exe) $($(exe)_OBJS)) \
- $(foreach lib,$(LIBS),$(lib) $($(lib)_OBJS)) \
- $(foreach lib,$(HOST_LIBS),$(lib) $($(lib)_OBJS))
-
-DESTDIR ?= /
-BINDIR ?= /usr/bin
-LIBDIR ?= /usr/lib
-
-.PHONY: install
-install:
- $(if $(EXES),\
- install -m 0755 -d $(DESTDIR)$(BINDIR) && \
- install -m 0755 $(EXES) $(DESTDIR)$(BINDIR) \
- )
- $(if $(LIBS),\
- install -m 0755 -d $(DESTDIR)$(LIBDIR)/host-ipmid && \
- install -m 0755 $(HOST_LIBS) $(DESTDIR)$(LIBDIR)/host-ipmid && \
- install -m 0755 $(LIBS) $(DESTDIR)$(LIBDIR) \
- )
-
-.DEFAULT_GOAL: all
-.PHONY: all
-all: $(EXES) $(LIBS)
diff --git a/cmake/sdbus.cmake b/cmake/sdbus.cmake
new file mode 100644
index 0000000..90806f3
--- /dev/null
+++ b/cmake/sdbus.cmake
@@ -0,0 +1,16 @@
+find_library(SYSTEMD_LIBRARY systemd)
+if(NOT SYSTEMD_LIBRARY)
+ message(FATAL_ERROR "Cannot find libsystemd.")
+endif(NOT SYSTEMD_LIBRARY)
+
+find_path(SYSTEMD_SDBUS_INCLUDE "systemd/sd-bus.h")
+if(NOT SYSTEMD_SDBUS_INCLUDE)
+ message(FATAL_ERROR "Cannot find sd-bus.h, libsystemd doesn't support?")
+endif(NOT SYSTEMD_SDBUS_INCLUDE)
+include_directories(${SYSTEMD_SDBUS_INCLUDE})
+
+INCLUDE (CheckLibraryExists)
+CHECK_LIBRARY_EXISTS(systemd sd_bus_open SYSTEMD_LIBRARY SYSTEMD_HAVE_SDBUS)
+if(NOT SYSTEMD_HAVE_SDBUS)
+ message(FATAL_ERROR "libsystemd doesn't support sdbus functions.")
+endif(NOT SYSTEMD_HAVE_SDBUS)
--
2.7.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH ipmi-fru-parser] RFC: use cmake.
2016-03-03 22:30 ` [PATCH ipmi-fru-parser] RFC: use cmake OpenBMC Patches
@ 2016-03-07 4:00 ` Joel Stanley
2016-03-08 2:53 ` Patrick Williams
0 siblings, 1 reply; 6+ messages in thread
From: Joel Stanley @ 2016-03-07 4:00 UTC (permalink / raw)
To: OpenBMC Patches; +Cc: OpenBMC Maillist
On Fri, Mar 4, 2016 at 9:00 AM, OpenBMC Patches
<openbmc-patches@stwcx.xyz> wrote:
> From: Patrick Williams <patrick@stwcx.xyz>
>
> There was a previous proposal to consider autotools (see
> openbmc/ipmi-fru-parser#7). This is an alternative implementation
> using cmake.
I'm not a fan of autotools; I have not chosen to use it on small
projects in the past.
That said, I have stopped working on projects due to cmake's
downsides. It's overly complex, and no clear way to implement rules,
making it hard for newbies and experienced developers alike.
I would prefer to see autotools implemented by one of our team members
that has experience with it, and they can help the rest of us maintain
it.
I noticed in my feeds a new project created by some of the Xorg
developers that is a nice example of a clean, well structured project
that uses systemd, dbus, and autotools can be found here:
https://github.com/libratbag/ratbagd
Cheers,
Joel
> ---
> .gitignore | 12 +++++++++
> CMakeLists.txt | 30 ++++++++++++++++++++++
> Makefile | 75 -------------------------------------------------------
> cmake/sdbus.cmake | 16 ++++++++++++
> 4 files changed, 58 insertions(+), 75 deletions(-)
> create mode 100644 .gitignore
> create mode 100644 CMakeLists.txt
> delete mode 100644 Makefile
> create mode 100644 cmake/sdbus.cmake
>
> diff --git a/.gitignore b/.gitignore
> new file mode 100644
> index 0000000..727471a
> --- /dev/null
> +++ b/.gitignore
> @@ -0,0 +1,12 @@
> +#### vi files ####
> +*.swp
> +#### --- vi --- ####
> +
> +#### CMAKE Files ####
> +CMakeCache.txt
> +CMakeFiles
> +CMakeScripts
> +Makefile
> +cmake_install.cmake
> +install_manifest.txt
> +#### --- CMAKE --- ####
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> new file mode 100644
> index 0000000..0a00985
> --- /dev/null
> +++ b/CMakeLists.txt
> @@ -0,0 +1,30 @@
> +cmake_minimum_required(VERSION 3.1)
> +project(ipmi-fru-parser)
> +
> +set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")
> +set(CMAKE_CXX_STANDARD 14)
> +set(CMAKE_CXX_STANDARD_REQUIRED on)
> +
> +include("cmake/sdbus.cmake")
> +
> +add_library(writefrudata SHARED
> + frup.c
> + writefrudata.C
> +)
> +target_link_libraries(writefrudata ${SYSTEMD_LIBRARY})
> +install(TARGETS writefrudata LIBRARY DESTINATION lib/host-ipmid)
> +
> +add_library(strgfnhandler SHARED
> + strgfnhandler.C
> +)
> +target_link_libraries(strgfnhandler writefrudata)
> +install(TARGETS strgfnhandler LIBRARY DESTINATION lib)
> +
> +add_executable(phosphor-read-eeprom
> + argument.C
> + readeeprom.C
> +)
> +target_link_libraries(phosphor-read-eeprom writefrudata)
> +target_link_libraries(phosphor-read-eeprom ${SYSTEMD_LIBRARY})
> +
> +install(TARGETS phosphor-read-eeprom RUNTIME DESTINATION bin)
> diff --git a/Makefile b/Makefile
> deleted file mode 100644
> index dc66a77..0000000
> --- a/Makefile
> +++ /dev/null
> @@ -1,75 +0,0 @@
> -LIBS += libwritefrudata.so
> -HOST_LIBS += libstrgfnhandler.so
> -libwritefrudata.so_OBJS += frup.o writefrudata.o
> -libstrgfnhandler.so_OBJS += strgfnhandler.o
> -
> -EXES += phosphor-read-eeprom
> -
> -phosphor-read-eeprom_OBJS += readeeprom.o argument.o
> -phosphor-read-eeprom_EXTRA_LIBS += writefrudata
> -libstrgfnhandler.so_EXTRA_LIBS += writefrudata
> -libwritefrudata.so_NEEDED += libsystemd
> -phosphor-read-eeprom_NEEDED += libsystemd
> -
> -#### -----------------------------------------------------------------------####
> -# #
> -## Compilare Regulas Sequi ##
> -# #
> -#### -----------------------------------------------------------------------####
> -OPTFLAGS ?= -O3 -g -pipe -G -K
> -CFLAGS ?= $(OPTFLAGS)
> -CXXFLAGS ?= $(OPTFLAGS)
> -CFLAGS += -Wall -flto -fPIC
> -CXXFLAGS += --std=gnu++14 -Wall -flto -fPIC
> -
> -__PKG_CONFIG = $(if $1,$(shell pkg-config $2 $1))
> -__EXTRA_LIB_RESOLV = $(if $1,$1)
> -
> -define __BUILD_EXE
> -$1 : $$($1_OBJS) | $$(LIBS) $$(HOST_LIBS)
> - $$(LINK.cpp) -o $$@ $$^ $(call __EXTRA_LIB_RESOLV,$(addprefix -l,$($1_EXTRA_LIBS))) -L. $(call __PKG_CONFIG,$($1_NEEDED),--libs)
> -
> -$(eval CXXFLAGS += $(call __PKG_CONFIG,$($1_NEEDED),--cflags))
> -
> -#include $$($1_OBJS:.o=.d)
> -endef
> -
> -$(foreach exe,$(EXES),$(eval $(call __BUILD_EXE,$(exe))))
> -
> -define __BUILD_LIB
> -$1 : $$($1_OBJS) | $$(addsuffix .so,$$(addprefix lib,$$($1_EXTRA_LIBS)))
> - $$(LINK.cpp) -fPIC -shared -o $$@ $$^ $(call __EXTRA_LIB_RESOLV,$(addprefix -l,$($1_EXTRA_LIBS))) -L. $(call __PKG_CONFIG,$($1_NEEDED),--libs)
> -
> -$(eval CXXFLAGS += $(call __PKG_CONFIG,$($1_NEEDED),--cflags))
> -
> -#include $$($1_OBJS:.o=.d)
> -endef
> -
> -$(foreach lib,$(LIBS),$(eval $(call __BUILD_LIB,$(lib))))
> -$(foreach lib,$(HOST_LIBS),$(eval $(call __BUILD_LIB,$(lib))))
> -
> -.PHONY: clean
> -clean:
> - $(RM) $(foreach exe,$(EXES),$(exe) $($(exe)_OBJS)) \
> - $(foreach lib,$(LIBS),$(lib) $($(lib)_OBJS)) \
> - $(foreach lib,$(HOST_LIBS),$(lib) $($(lib)_OBJS))
> -
> -DESTDIR ?= /
> -BINDIR ?= /usr/bin
> -LIBDIR ?= /usr/lib
> -
> -.PHONY: install
> -install:
> - $(if $(EXES),\
> - install -m 0755 -d $(DESTDIR)$(BINDIR) && \
> - install -m 0755 $(EXES) $(DESTDIR)$(BINDIR) \
> - )
> - $(if $(LIBS),\
> - install -m 0755 -d $(DESTDIR)$(LIBDIR)/host-ipmid && \
> - install -m 0755 $(HOST_LIBS) $(DESTDIR)$(LIBDIR)/host-ipmid && \
> - install -m 0755 $(LIBS) $(DESTDIR)$(LIBDIR) \
> - )
> -
> -.DEFAULT_GOAL: all
> -.PHONY: all
> -all: $(EXES) $(LIBS)
> diff --git a/cmake/sdbus.cmake b/cmake/sdbus.cmake
> new file mode 100644
> index 0000000..90806f3
> --- /dev/null
> +++ b/cmake/sdbus.cmake
> @@ -0,0 +1,16 @@
> +find_library(SYSTEMD_LIBRARY systemd)
> +if(NOT SYSTEMD_LIBRARY)
> + message(FATAL_ERROR "Cannot find libsystemd.")
> +endif(NOT SYSTEMD_LIBRARY)
> +
> +find_path(SYSTEMD_SDBUS_INCLUDE "systemd/sd-bus.h")
> +if(NOT SYSTEMD_SDBUS_INCLUDE)
> + message(FATAL_ERROR "Cannot find sd-bus.h, libsystemd doesn't support?")
> +endif(NOT SYSTEMD_SDBUS_INCLUDE)
> +include_directories(${SYSTEMD_SDBUS_INCLUDE})
> +
> +INCLUDE (CheckLibraryExists)
> +CHECK_LIBRARY_EXISTS(systemd sd_bus_open SYSTEMD_LIBRARY SYSTEMD_HAVE_SDBUS)
> +if(NOT SYSTEMD_HAVE_SDBUS)
> + message(FATAL_ERROR "libsystemd doesn't support sdbus functions.")
> +endif(NOT SYSTEMD_HAVE_SDBUS)
> --
> 2.7.1
>
>
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH ipmi-fru-parser] RFC: use cmake.
2016-03-07 4:00 ` Joel Stanley
@ 2016-03-08 2:53 ` Patrick Williams
2016-03-08 9:46 ` Stewart Smith
0 siblings, 1 reply; 6+ messages in thread
From: Patrick Williams @ 2016-03-08 2:53 UTC (permalink / raw)
To: Joel Stanley; +Cc: OpenBMC Patches, OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 2314 bytes --]
Joel,
On Mon, Mar 07, 2016 at 02:30:51PM +1030, Joel Stanley wrote:
> On Fri, Mar 4, 2016 at 9:00 AM, OpenBMC Patches
> <openbmc-patches@stwcx.xyz> wrote:
> > From: Patrick Williams <patrick@stwcx.xyz>
> >
> > There was a previous proposal to consider autotools (see
> > openbmc/ipmi-fru-parser#7). This is an alternative implementation
> > using cmake.
>
> I'm not a fan of autotools; I have not chosen to use it on small
> projects in the past.
>
> That said, I have stopped working on projects due to cmake's
> downsides. It's overly complex, and no clear way to implement rules,
> making it hard for newbies and experienced developers alike.
Can you elaborate on this? I honestly don't have much experience with
CMake but from the little I have played with it it seems 5x easier than
makefiles (which autotools still use via Makefile.am).
Compare the gigantic m4 script required to test C++14 support in
autotools vs two lines in CMake:
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED on)
> I would prefer to see autotools implemented by one of our team members
> that has experience with it, and they can help the rest of us maintain
> it.
It isn't just a one-repository thing though. What is going to happen is
that even a well-written autotools is going to get copied and modified
and copied and modified into all the various openbmc repositories.
We're going to need a few autotools experts to keep watch over
everything and avoid hit-by-bus situations.
>
> I noticed in my feeds a new project created by some of the Xorg
> developers that is a nice example of a clean, well structured project
> that uses systemd, dbus, and autotools can be found here:
>
> https://github.com/libratbag/ratbagd
>
That example has a 290 line m4 script, 160 line configure script, and a
100 line makefile just to build an executable out of 6 .c files. Even
if it is "clean" there is way too much to consume here.
The "meat" of the dependency description is in these lines:
PKG_CHECK_MODULES([LIBUDEV], [libudev])
PKG_CHECK_MODULES([LIBSYSTEMD], [libsystemd >= 227])
PKG_CHECK_MODULES([LIBRATBAG], [libratbag >= 0.2])
CMake has a similar macro via 'find_package'.
> Cheers,
>
> Joel
>
--
Patrick Williams
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH ipmi-fru-parser] RFC: use cmake.
2016-03-08 2:53 ` Patrick Williams
@ 2016-03-08 9:46 ` Stewart Smith
2016-03-11 3:55 ` Stewart Smith
0 siblings, 1 reply; 6+ messages in thread
From: Stewart Smith @ 2016-03-08 9:46 UTC (permalink / raw)
To: Patrick Williams, Joel Stanley; +Cc: OpenBMC Maillist, OpenBMC Patches
Patrick Williams <patrick@stwcx.xyz> writes:
> On Mon, Mar 07, 2016 at 02:30:51PM +1030, Joel Stanley wrote:
>> On Fri, Mar 4, 2016 at 9:00 AM, OpenBMC Patches
>> <openbmc-patches@stwcx.xyz> wrote:
>> > From: Patrick Williams <patrick@stwcx.xyz>
>> >
>> > There was a previous proposal to consider autotools (see
>> > openbmc/ipmi-fru-parser#7). This is an alternative implementation
>> > using cmake.
>>
>> I'm not a fan of autotools; I have not chosen to use it on small
>> projects in the past.
>>
>> That said, I have stopped working on projects due to cmake's
>> downsides. It's overly complex, and no clear way to implement rules,
>> making it hard for newbies and experienced developers alike.
>
> Can you elaborate on this? I honestly don't have much experience with
> CMake but from the little I have played with it it seems 5x easier than
> makefiles (which autotools still use via Makefile.am).
Some getting started bits are easier in CMake, that's true. But CMake
misses a few important things:
1) a defined language. M4 is awful (and portable shell is also
annoying), but at least they are defined things. This cannot be said
for CMake, much of the language reference is... either found in
examples or the CMake source.
The CMake book was so bad I threw it out. If there wasn't risk of
starting a fire, I would have burnt it.
2) make dist.
This seems pretty easy to break with CMake, and is more important
than most people realise if you're going to support a relatively wide
range of development and build environments and don't want to be very
closely tied to a *specific* version of CMake that you're going to
have to port to whatever OS you build on.
I've been in situations where we had to do custom CMake RPMs for
RHEL N-1 because otherwise you couldn't compile the project on that
RHEL version and on the latest ubuntu/fedora.
Autotools gets you: "./configure && make && make install"
Cmake gets you: "First, port CMake version X.Y to your OS version"
Make dist is also important if you generate some source files
(e.g. you use bison) - as a source tarball can include generated
source files so you don't have the added build dependency of a
particular version of bison or something.
For the worst case, you end up with 20 lines of IF()s checking
platforms, targets, CMake versions and enabling weird choices. This
is the reality of MySQL's Cmake today :(
3)
So much of CMake gets tied to "version X of Y" rather than checking
the capabilities of something... pretty much every reference on the
internet as to how to enable/disable a complier flag is all
IF(COMPILER_IS_MSVC) X ELSEIF(COMPILER_IS_GNU)
ELSIF(COMPILER_IS_CLANG) IF(OSX_CLANG) ENDIF ENDIF.
This is very true for compiler flags, which it's much more sensible
to go and check if teh compiler supports them or not - that would
enable you to build with any toolchain and for the build system to
sort things out.
4) comprehensive archive of recipies for detecting interesting things.
A big Cmake project (MySQL) gets to keep the following:
https://github.com/mysql/mysql-server/blob/5.7/cmake/bison.cmake
and some other odd things that really should be upstream archives.
While with autotools you get autoconf-archive having an amazing array
of automagic to drop in, and that "just works" with old distros,
producing a ./configure that will run on pretty much any POSIX-y OS
released in the past 25 years (to at least tell you why your OS isn't
going to cut it).
Conversely, it means that a project released now has a hope of
building in the future, and it's why you can still compile all sorts
of old projects today, and you don't need to port them up to using
the latest autofoo - the generated shell and Make "just work".
5) CMake is actually just metaprogramming. It's constructing something
to then go out and construct your Make... or your Visual Studio project
files... or your whatever. The biggest problem with this is debugging
it. With autotools, when you get things wrong, you get a bunch of
broken shell and Make to poke at to work out where you may have gone
wrong. With CMake, you get a cryptic error from the CMake binary -
which is fine if you're the kind of person who likes C++ templating
build errors :)
On the pro-Cmake side: it does enable you to keep one set of makefiles
for Windows and Linux/UNIX. After years of dealing with CMake in
MySQL... that's the only advantage I could come up with, and the only
reason why MySQL switched to CMake from (very bad) autotools.
>
> Compare the gigantic m4 script required to test C++14 support in
> autotools vs two lines in CMake:
> set(CMAKE_CXX_STANDARD 14)
> set(CMAKE_CXX_STANDARD_REQUIRED on)
autoconf archive has a c++14 macro:
https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx_14.html#ax_cxx_compile_stdcxx_14
Generally speaking, the autoconf archive gets things to do a bunch of
bleeding edge things, and you can keep a copy of these m4 macros in a
project m4/ directory so you don't require developers to have the same
autoconf archive version as you.
So it'd actually just be one line :)
>> I would prefer to see autotools implemented by one of our team members
>> that has experience with it, and they can help the rest of us maintain
>> it.
>
> It isn't just a one-repository thing though. What is going to happen is
> that even a well-written autotools is going to get copied and modified
> and copied and modified into all the various openbmc repositories.
> We're going to need a few autotools experts to keep watch over
> everything and avoid hit-by-bus situations.
For what we're dealing with in OpenBMC, it'd be pretty trivial autotools.
>> I noticed in my feeds a new project created by some of the Xorg
>> developers that is a nice example of a clean, well structured project
>> that uses systemd, dbus, and autotools can be found here:
>>
>> https://github.com/libratbag/ratbagd
>>
>
> That example has a 290 line m4 script, 160 line configure script, and a
> 100 line makefile just to build an executable out of 6 .c files. Even
> if it is "clean" there is way too much to consume here.
attributes.m4 I *think* (I haven't looked too closely at that script)
should actually be superceded by AX_CHECK_COMPILE_FLAG from
autoconf-archive, so that should go away.
the 160 line configure script is actually 124 when you exclude comments
and whitespace, 115 when you exclude the extra verbose printing. Out of
those 115 lines, 42 are checks for compiler flags, one per line -
they're being good and paranoid with warnings (which you'd have to do
this in cmake too). Another 7 lines for linker flags, a dozen for debug
specific options.
The actual boilerplate is pretty much only:
AC_PREREQ([2.64]) <- needs this autoconf version. Also needed in Cmake projects
AC_CONFIG_SRCDIR([src/ratbagd.h])
AC_CONFIG_MACRO_DIR([m4])
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_AUX_DIR([build-aux])
(okay, fair enough, this is boilerplate, but you need most of these
equivalents for non-trivial cmake too)
AM_INIT_AUTOMAKE([foreign 1.11 -Wall -Wno-portability silent-rules tar-pax no-d\
ist-gzip dist-xz subdir-objects parallel-tests])
also mostly boilerplate, although you're going to need CTest setup in
Cmake and possibly other CPackage things to get make dist working.
LT_PREREQ(2.2)
LT_INIT([disable-static])
Libtool init, largely boilerplate.
AC_OUTPUT <- the command to output things, again, boilerplate.
So there's not much boilerplate... it's mostly things you'd have to do
in Cmake too to get equivalent functionality on the configure side.
AS for building, it's not just 6 C files. You have including the systemd
service, the python module, and using a convienience library (probabyl
not needed... but it can be a good choice).
The only real boilerplate is three lines:
ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}
AM_MAKEFLAGS = --no-print-directory
AUTOMAKE_OPTIONS = color-tests parallel-tests
Everything else would need Cmake equivalents (except the empty
assignments that aren't actually needed).
So there's not a big difference in verbosity of build system for
equivalent functionality.
--
Stewart Smith
OPAL Architect, IBM.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH ipmi-fru-parser] RFC: use cmake.
2016-03-08 9:46 ` Stewart Smith
@ 2016-03-11 3:55 ` Stewart Smith
0 siblings, 0 replies; 6+ messages in thread
From: Stewart Smith @ 2016-03-11 3:55 UTC (permalink / raw)
To: Patrick Williams, Joel Stanley; +Cc: OpenBMC Maillist, OpenBMC Patches
Stewart Smith <stewart@linux.vnet.ibm.com> writes:
> Patrick Williams <patrick@stwcx.xyz> writes:
>> On Mon, Mar 07, 2016 at 02:30:51PM +1030, Joel Stanley wrote:
>>> On Fri, Mar 4, 2016 at 9:00 AM, OpenBMC Patches
>>> <openbmc-patches@stwcx.xyz> wrote:
>>> > From: Patrick Williams <patrick@stwcx.xyz>
>>> >
>>> > There was a previous proposal to consider autotools (see
>>> > openbmc/ipmi-fru-parser#7). This is an alternative implementation
>>> > using cmake.
>>>
>>> I'm not a fan of autotools; I have not chosen to use it on small
>>> projects in the past.
>>>
>>> That said, I have stopped working on projects due to cmake's
>>> downsides. It's overly complex, and no clear way to implement rules,
>>> making it hard for newbies and experienced developers alike.
>>
>> Can you elaborate on this? I honestly don't have much experience with
>> CMake but from the little I have played with it it seems 5x easier than
>> makefiles (which autotools still use via Makefile.am).
>
> Some getting started bits are easier in CMake, that's true. But CMake
> misses a few important things:
Tridge on CMake:
https://lists.samba.org/archive/samba-technical/2010-February/069670.html
--
Stewart Smith
OPAL Architect, IBM.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-03-11 3:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-03 22:30 [PATCH ipmi-fru-parser] RFC: use cmake. (DO NOT MERGE) OpenBMC Patches
2016-03-03 22:30 ` [PATCH ipmi-fru-parser] RFC: use cmake OpenBMC Patches
2016-03-07 4:00 ` Joel Stanley
2016-03-08 2:53 ` Patrick Williams
2016-03-08 9:46 ` Stewart Smith
2016-03-11 3:55 ` Stewart Smith
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.