mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Bannier <benjamin.bann...@mesosphere.io>
Subject Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.
Date Wed, 04 Apr 2018 06:27:47 GMT


> On März 28, 2018, 10:06 vorm., 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.

There's no guarantee this search will succeed, e.g., no make program could be installed. Let's
check we found _something_ before continuing.


- Benjamin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/66314/#review200098
-----------------------------------------------------------


On April 4, 2018, 5:33 vorm., David Forsythe wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66314/
> -----------------------------------------------------------
> 
> (Updated April 4, 2018, 5:33 vorm.)
> 
> 
> 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/2/
> 
> 
> Testing
> -------
> 
> make on FreeBSD
> 
> 
> Thanks,
> 
> David Forsythe
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message