> On March 28, 2018, 10: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?
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()
- Benjamin
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/66314/#review200098
-----------------------------------------------------------
On April 2, 2018, 8: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, 8: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
>
>
