> On March 28, 2018, 8:06 a.m., Benjamin Bannier wrote: > > 3rdparty/CMakeLists.txt > > Lines 58-63 (patched) > > <https://reviews.apache.org/r/66314/diff/1/?file=1989124#file1989124line58> > > > > Like discussed offline, I don't think there is a reason we need to bolt > > such logic on the used system, at least currently. > > > > Let's instead use `find_program` to find a `make` and use it to set > > this variable. > > > > Unless I miss something, we do not depend on GNU make here, so let's > > maybe reflect that in a more general name, e.g., just `MAKE` if it is > > available. > > David Forsythe wrote: > I took a look at find_program, but I don't think that will solve the > problem. > > We actually *do* depend on gmake here (even on darwin). On FreeBSD GHU > make is a 3rd party application and is actually called and installed as > `gmake`, whereas the system make is actually Pmake (which is incompatible). > > David Forsythe wrote: > I should clarify that there is incompability in a 3rdparty Makefile, not > that the two makes are completely incompatible. > > Particularly there are three issues - LevelDB, libev, and glog. > > LevelDB is always going to fail without `gmake`, because it does not use > autotools. I don't know how we can get around that. > > libev and glog do use autotools. They have some strange behavior when > building, though -- > If I use `cmake --build` they both fail on a bad target (because of an > incompatible Makefile). > If I use (bsd) `make`, they build fine. > If I use `gmake` they both fail (bad target). > > For both the first and third scenario, I can run the commands that are > failing outside of the build and they succeed. > > Accordng to the cache, cmake is using `gmake` as `CMAKE_MAKE_PROGRAM` in > these cases, so it's not clear to me why anything would fail when I do the > whole build with `gmake`. It seems like the build can go make -> gmake, but > not gmake -> make. > > I think the baseline should be having `cmake --build` work, and the only > way I have gotten everything to work as expected is by forcing `gmake` > everywhere. I'm learning Cmake as I go so I could be missing something > obvious to fix this.
I've been thinking about this a bit more, and I think that the best approach might actually be to just leave the libev and glog calls as make and leave the conditional gmake call. On FreeBSD we could just tell users to use `make` instead of cmake build. It seems like a way less intrusive change. Thoughts? - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66314/#review200098 ----------------------------------------------------------- On April 2, 2018, 6:36 p.m., David Forsythe wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/66314/ > ----------------------------------------------------------- > > (Updated April 2, 2018, 6:36 p.m.) > > > Review request for mesos, Andrew Schwartzmeyer and Benjamin Bannier. > > > Bugs: MESOS-4176 > https://issues.apache.org/jira/browse/MESOS-4176 > > > Repository: mesos > > > Description > ------- > > Fix 3rdparty build commands for FreeBSD. > > > Diffs > ----- > > 3rdparty/CMakeLists.txt 2b63b58f7d6a88c9986b746283dcfa79b7bcb270 > cmake/CompilationConfigure.cmake 64cc56ee4208afe05df0f28af5890157e4c7d82c > > > Diff: https://reviews.apache.org/r/66314/diff/1/ > > > Testing > ------- > > cmake --build on FreeBSD > > > Thanks, > > David Forsythe > >
