cmake script builds and installs a different version than the makefile #506

Merged
gabm merged 1 commit from fix-cmake into dev 2021-03-10 03:46:17 -06:00
gabm commented 2021-03-08 08:52:18 -06:00 (Migrated from github.com)

From a packaging point of view, it would be great to achieve parity between the binaries and install created by the Makefile and cmake. 3 things stand in the way

  1. the SONAME is different (I consider this a copy-paste bug in the current script)
  2. some additional CFLAGS get added to the compiler flags. The Makefile does not mess with that. Let's do the same! on a minor note: the makefile uses both: CFLAGS and CPPFLAGS which is dubious, given that we only build a C lib
  3. the pkg-config file does not get created and installed
  4. symlinks for {xxh128, xxh64, xxh32} -> xxhsum are being created by the Makefile, cmake only installs xxhsum

This PR solves the first 3 problems. Not sure about 4?

From a packaging point of view, it would be great to achieve parity between the binaries and install created by the Makefile and cmake. 3 things stand in the way 1. the SONAME is different (I consider this a copy-paste bug in the current script) 2. some additional CFLAGS get added to the compiler flags. The Makefile does not mess with that. Let's do the same! *on a minor note*: the makefile uses both: `CFLAGS` and `CPPFLAGS` which is dubious, given that we only build a C lib 3. the pkg-config file does not get created and installed 4. symlinks for `{xxh128, xxh64, xxh32} -> xxhsum` are being created by the Makefile, cmake only installs `xxhsum` This PR solves the first 3 problems. Not sure about 4?
Cyan4973 (Migrated from github.com) reviewed 2021-03-08 08:52:18 -06:00
Cyan4973 commented 2021-03-08 10:46:26 -06:00 (Migrated from github.com)

the makefile uses both: CFLAGS and CPPFLAGS which is dubious, given that we only build a C lib

CPPFLAGS stands for "C PreProcessor Flags".
So yes, it's needed.

This PR solves the first 3 problems. Not sure about 4?

Adding symlinks is a secondary topic,
it is not required for this PR.

> the makefile uses both: CFLAGS and CPPFLAGS which is dubious, given that we only build a C lib `CPPFLAGS` stands for "C PreProcessor Flags". So yes, it's needed. > This PR solves the first 3 problems. Not sure about 4? Adding symlinks is a secondary topic, it is not required for this PR.
Cyan4973 commented 2021-03-08 10:47:12 -06:00 (Migrated from github.com)

minor :
it seems a formatting test detected a few trailing white spaces in updated CMakeLists.txt

minor : it seems a formatting test detected a few trailing white spaces in updated `CMakeLists.txt`
gabm commented 2021-03-08 10:48:01 -06:00 (Migrated from github.com)

CPPFLAGS stands for "C PreProcessor Flags".

this is embarrassing. so many years of programming and I assumed it meant "C++"...

> CPPFLAGS stands for "C PreProcessor Flags". this is embarrassing. so many years of programming and I assumed it meant "C++"...
gabm commented 2021-03-08 10:54:12 -06:00 (Migrated from github.com)

hopefully I catched all whitespaces

hopefully I catched all whitespaces
gabm commented 2021-03-08 12:31:44 -06:00 (Migrated from github.com)

looks good @Cyan4973 👍

looks good @Cyan4973 👍
Cyan4973 (Migrated from github.com) approved these changes 2021-03-08 13:54:38 -06:00
gabm commented 2021-03-08 14:32:49 -06:00 (Migrated from github.com)

oops sorry, that was unintended

oops sorry, that was unintended
gabm commented 2021-03-10 03:12:55 -06:00 (Migrated from github.com)

@Cyan4973 thanks for approving the changes. Would you also merge? or is there another policy?

@Cyan4973 thanks for approving the changes. Would you also merge? or is there another policy?
Cyan4973 commented 2021-03-10 03:46:13 -06:00 (Migrated from github.com)

no, just waiting a bit, in case external comments show up.
Should be fine now.

no, just waiting a bit, in case external comments show up. Should be fine now.
Sign in to join this conversation.
No description provided.