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