While compiling cmake for SerenityOS on an update of cmake to 3.26.4, I
noticed a compiler warning for an implicit declaration of select
.
POSIX specifies that select
is found in <sys/select.h>
, so add that
include here.
Shannon Booth (822aa365) at 15 Jul 06:58
ProcessUNIX: Fix implicit definition of select
While compiling cmake for SerenityOS on an update of cmake to 3.26.4, I
noticed a compiler warning for an implicit declaration of select
.
POSIX specifies that select
is found in <sys/select.h>
, so add that
include here.
Shannon Booth (c32af6e7) at 14 Jul 21:18
ProcessUNIX: Fix implicit definition of select
Thanks @marc.chevrier, noted.
If at all possible, I am hoping that I could somehow implement patch in a way where I do not need to pull in kwsys directly into the project and allow it to also be compiled standalone. Currently I use:
std::fileystem::path
std::filesytem::exists
std::filesystem::remove
std::filesystem::create_directories
std::filesystem::file_size
std::filesystem::is_regular_file
I am also thinking of soon using std::filesystem::permissions
at some point to implement changing the mode of a file. (e.g adding executable bit in git style mode patch).
std::filesystem::path
seems to already be provided by Utilities/std/cm/filesystem
if I understand correctly.
Would it be fine if I had a filesystem.h
(or similar) which when compiled standalone would be implemented by std::filesystem
, but when integrated into CMake was implemented by CMake's existing facilities? e.g std::filesystem::exists
implemented by SystemTools::PathExists
? Or is there a better approach here?
Thanks for the hint on cmsys::fstream
. I can add in a hook to use this implementation instead of std::fstream
.
Continuing on the topic of portability - I currently have a chunk of my tests written using python. Is this fine? I imagine that not all of the runners which CMake employs have python installed on them. The tests could obviously be skipped if python is not installed. But I am not sure if this meets the expectations here. Let me know if there is anything I would need to do here instead.
Thanks @marc.chevrier - yup, that makes sense.
Looking around at that code - I am also wondering whether it would it also be acceptable if Utilities/std/cm/filesystem
were extended to include the functions which are needed?
@brad.king @ben.boeckel @kyle.edwards I've been working on an implementation of patch.
I'm still working on it, but it supports all of the options defined by POSIX other than ed style patch support. I've also tried my best to maintain compatibility with the observed behavior of GNU patch.
I've also made a stab at writing it as cross platform as possible. It's written in C++11 for the most part other than its usage of std::filesystem.
Would this be something that the cmake project would be happy with integrating at some stage in the future?