> 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. > > David Forsythe wrote: > 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? > > Benjamin Bannier wrote: > I think it should be perfectly fine to use `gmake` if it is available, it > is usually a symlink to `make` anyway. > > The implementation I was thinking of was to add below instead, > > find_program( > GNU_MAKE > NAMES gmake make > DOC "path to GNU make executable") > > if (NOT GNU_MAKE) > message(FATAL_ERROR "Could not find a suitable GNU make executable") > endif() > > David Forsythe wrote: > This would always succeed on FreeBSD (or any system with a make), even if > gmake wasn't installed. It is not a symlink: > > ``` > > root@mesos0:/mesos-build # gmake --version > GNU Make 4.2.1 > ... > root@mesos0:/mesos-build # make --version > usage: make [-BeikNnqrstWwX] > ... > > ``` > > With autotools we didn't run into this because (iirc) so much was > incompatible that I just used/assumed `gmake` for everything. With `cmake` > we're close enough that I think it might be worth it to try and support bsd > make. > > David Forsythe wrote: > I made everything use `gmake`, but I didn't add the check/message because > the check always succeeds. Added a TODO as discussed offline. > > Benjamin Bannier wrote: > There's no guarantee this search will succeed, e.g., no make program > could be installed. Let's check we found _something_ before continuing.
You got it. I renamed `GNU_MAKE` to `EXTERNAL_MAKE` since we're just looking for anything that matches. - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66314/#review200098 ----------------------------------------------------------- On April 4, 2018, 6:45 a.m., David Forsythe wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/66314/ > ----------------------------------------------------------- > > (Updated April 4, 2018, 6:45 a.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 > > > Diff: https://reviews.apache.org/r/66314/diff/3/ > > > Testing > ------- > > make on FreeBSD > > > Thanks, > > David Forsythe > >
