Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-04 Thread Mesos Reviewbot Windows 

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



FAIL: Some of the unit tests failed. Please check the relevant logs.

Reviews applied: `['66314']`

Failed command: `Start-MesosCITesting`

All the build artifacts available at: 
http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66314

Relevant logs:

- 
[mesos-tests-stdout.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66314/logs/mesos-tests-stdout.log):

```
[   OK ] Endpoint/SlaveEndpointTest.NoAuthorizer/2 (114 ms)
[--] 9 tests from Endpoint/SlaveEndpointTest (1071 ms total)

[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0 (34 
ms)
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1 (38 
ms)
[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest (74 ms 
total)

[--] 1 test from IsolationFlag/CpuIsolatorTest
[ RUN  ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0
[   OK ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0 (766 ms)
[--] 1 test from IsolationFlag/CpuIsolatorTest (791 ms total)

[--] 1 test from IsolationFlag/MemoryIsolatorTest
[ RUN  ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0
[   OK ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0 (842 ms)
[--] 1 test from IsolationFlag/MemoryIsolatorTest (868 ms total)

[--] Global test environment tear-down
[==] 949 tests from 94 test cases ran. (457107 ms total)
[  PASSED  ] 948 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] CommandExecutorCheckTest.CommandCheckTimeout

 1 FAILED TEST
  YOU HAVE 214 DISABLED TESTS

```

- 
[mesos-tests-stderr.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66314/logs/mesos-tests-stderr.log):

```
I0404 15:34:29.087707  4724 master.cpp:10449] Updating the state of task 
f2abc4a7-0333-48dd-aa68-31c49aa6cb80 of framework 
cd7c7eb7-a02d-457f-902d-bde2d9aebf5a- (latest state: TASK_KILLED, status 
update state: TASK_KILLED)
I0404 15:34:29.087707 11060 slave.cpp:3877] Shutting down framework 
cd7c7eb7-a02d-457f-902d-bde2d9aebf5a-
I0404 15:34:29.088703 11060 slave.cpp:6574] Shutting down executor 
'f2abc4a7-0333-48dd-aa68-31c49aa6cb80' of framework 
cd7c7eb7-a02d-457f-902d-bde2d9aebf5a- at executor(1)@10.3.1.8:64287
I0404 15:34:29.088703 11060 slave.cpp:923] Agent terminating
W0404 15:34:29.089694 11060 slave.cpp:3873] Ignoring shutdown framework 
cd7c7eb7-a02d-457f-902d-bde2d9aebf5a- because it is terminating
I0404 15:34:29.090912  4724 master.cpp:10548] Removing task 
f2abc4a7-0333-48dd-aa68-31c49aa6cb80 with resources cpus(allocated: *):4; 
mem(allocated: *):2048; disk(allocated: *):1024; ports(allocated: 
*):[31000-32000] of framework cd7c7eb7-a02d-457f-902d-bde2d9aebf5a- on 
agent cd7c7eb7-a02d-457f-902d-bde2d9aebf5a-S0 at slave(418)@1I0404 
15:34:28.887692  8764 exec.cpp:162] Version: 1.6.0
I0404 15:34:28.916703  3848 exec.cpp:236] Executor registered on agent 
cd7c7eb7-a02d-457f-902d-bde2d9aebf5a-S0
I0404 15:34:28.920713 13524 executor.cpp:176] Received SUBSCRIBED event
I0404 15:34:28.926687 13524 executor.cpp:180] Subscribed executor on 
winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net
I0404 15:34:28.927688 13524 executor.cpp:176] Received LAUNCH event
I0404 15:34:28.933684 13524 executor.cpp:648] Starting task 
f2abc4a7-0333-48dd-aa68-31c49aa6cb80
I0404 15:34:29.029688 13524 executor.cpp:483] Running 
'D:\DCOS\mesos\src\mesos-containerizer.exe launch '
I0404 15:34:29.057710 13524 executor.cpp:661] Forked command at 13908
I0404 15:34:29.089694  2304 exec.cpp:445] Executor asked to shutdown
I0404 15:34:29.090912 11452 executor.cpp:176] Received SHUTDOWN event
I0404 15:34:29.090912 11452 executor.cpp:758] Shutting down
I0404 15:34:29.091694 11452 executor.cpp:868] Sending SIGTERM to process tree 
at pid 0.3.1.8:64266 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net)
I0404 15:34:29.093690 14220 containerizer.cpp:2338] Destroying container 
c09116e7-f435-4624-afac-33f7e1746e84 in RUNNING state
I0404 15:34:29.093690 14220 containerizer.cpp:2952] Transitioning the state of 
container c09116e7-f435-4624-afac-33f7e1746e84 from RUNNING to DESTROYING
I0404 15:34:29.093690  4724 master.cpp:1295] Agent 
cd7c7eb7-a02d-457f-902d-bde2d9aebf5a-S0 at slave(418)@10.3.1.8:64266 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net) disconnected
I0404 15:34:29.094696  4724 master.cpp:3286] Disconnecting agent 
cd7c7eb7-a02d-457f-902d-bde2d9aebf5a-S0 at slave(418)@10.3.1.8:64266

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-04 Thread David Forsythe 

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

(Updated April 4, 2018, 2:34 p.m.)


Review request for mesos, Andrew Schwartzmeyer and Benjamin Bannier.


Changes
---

Changed `EXTERNAL_MAKE` to `MAKE_PROGRAM`.


Bugs: MESOS-4176
https://issues.apache.org/jira/browse/MESOS-4176


Repository: mesos


Description
---

Fix 3rdparty build commands for FreeBSD.


Diffs (updated)
-

  3rdparty/CMakeLists.txt 2b63b58f7d6a88c9986b746283dcfa79b7bcb270 


Diff: https://reviews.apache.org/r/66314/diff/4/

Changes: https://reviews.apache.org/r/66314/diff/3-4/


Testing
---

make on FreeBSD


Thanks,

David Forsythe

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-04 Thread Mesos Reviewbot 

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



Patch looks great!

Reviews applied: [66314]

Passed command: export OS='ubuntu:14.04' BUILDTOOL='autotools' COMPILER='gcc' 
CONFIGURATION='--verbose --disable-libtool-wrappers' ENVIRONMENT='GLOG_v=1 
MESOS_VERBOSE=1'; ./support/docker-build.sh

- Mesos Reviewbot


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
> 
>

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-04 Thread Mesos Reviewbot Windows 

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



FAIL: Some of the unit tests failed. Please check the relevant logs.

Reviews applied: `['66314']`

Failed command: `Start-MesosCITesting`

All the build artifacts available at: 
http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66314

Relevant logs:

- 
[mesos-tests-stdout.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66314/logs/mesos-tests-stdout.log):

```
[   OK ] Endpoint/SlaveEndpointTest.NoAuthorizer/2 (113 ms)
[--] 9 tests from Endpoint/SlaveEndpointTest (1074 ms total)

[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0 (33 
ms)
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1 (39 
ms)
[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest (75 ms 
total)

[--] 1 test from IsolationFlag/CpuIsolatorTest
[ RUN  ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0
[   OK ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0 (814 ms)
[--] 1 test from IsolationFlag/CpuIsolatorTest (844 ms total)

[--] 1 test from IsolationFlag/MemoryIsolatorTest
[ RUN  ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0
[   OK ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0 (817 ms)
[--] 1 test from IsolationFlag/MemoryIsolatorTest (842 ms total)

[--] Global test environment tear-down
[==] 949 tests from 94 test cases ran. (444889 ms total)
[  PASSED  ] 948 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] CommandExecutorCheckTest.CommandCheckTimeout

 1 FAILED TEST
  YOU HAVE 214 DISABLED TESTS

```

- 
[mesos-tests-stderr.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66314/logs/mesos-tests-stderr.log):

```
I0404 08:24:10.527199  2600 slave.cpp:3877] Shutting down framework 
d27be169-928d-44bf-b9cf-c0b66c4562f5-
I0404 08:24:10.527199  7224 master.cpp:10449] Updating the state of task 
af9512c0-aec1-4dd5-b047-2ec5fb30f3ba of framework d27be169-928d-44bfI0404 
08:24:10.344171  4216 exec.cpp:162] Version: 1.6.0
I0404 08:24:10.372175  5172 exec.cpp:236] Executor registered on agent 
d27be169-928d-44bf-b9cf-c0b66c4562f5-S0
I0404 08:24:10.376562 12312 executor.cpp:176] Received SUBSCRIBED event
I0404 08:24:10.381171 12312 executor.cpp:180] Subscribed executor on 
winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net
I0404 08:24:10.382174 12312 executor.cpp:176] Received LAUNCH event
I0404 08:24:10.387174 12312 executor.cpp:648] Starting task 
af9512c0-aec1-4dd5-b047-2ec5fb30f3ba
I0404 08:24:10.472184 12312 executor.cpp:483] Running 
'D:\DCOS\mesos\src\mesos-containerizer.exe launch '
I0404 08:24:10.501168 12312 executor.cpp:661] Forked command at 12424
I0404 08:24:10.529147  4228 exec.cpp:445] Executor asked to shutdown
I0404 08:24:10.530145 13964 executor.cpp:176] Received SHUTDOWN event
I0404 08:24:10.530145 13964 executor.cpp:758] Shutting down
I0404 08:24:10.530145 13964 executor.cpp:868] Sending SIGTERM to process tree 
at pid -b9cf-c0b66c4562f5- (latest state: TASK_KILLED, status update state: 
TASK_KILLED)
I0404 08:24:10.527199  2600 slave.cpp:6574] Shutting down executor 
'af9512c0-aec1-4dd5-b047-2ec5fb30f3ba' of framework 
d27be169-928d-44bf-b9cf-c0b66c4562f5- at executor(1)@10.3.1.8:57096
I0404 08:24:10.529147  7600 slave.cpp:923] Agent terminating
W0404 08:24:10.529147  7600 slave.cpp:3873] Ignoring shutdown framework 
d27be169-928d-44bf-b9cf-c0b66c4562f5- because it is terminating
I0404 08:24:10.530145  7224 master.cpp:10548] Removing task 
af9512c0-aec1-4dd5-b047-2ec5fb30f3ba with resources cpus(allocated: *):4; 
mem(allocated: *):2048; disk(allocated: *):1024; ports(allocated: 
*):[31000-32000] of framework d27be169-928d-44bf-b9cf-c0b66c4562f5- on 
agent d27be169-928d-44bf-b9cf-c0b66c4562f5-S0 at slave(418)@10.3.1.8:57075 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net)
I0404 08:24:10.532155  1124 containerizer.cpp:2338] Destroying container 
f6b7afe2-2176-4991-a7fc-c15fecf99239 in RUNNING state
I0404 08:24:10.533147  1124 containerizer.cpp:2952] Transitioning the state of 
container f6b7afe2-2176-4991-a7fc-c15fecf99239 from RUNNING to DESTROYING
I0404 08:24:10.533147  7224 master.cpp:1295] Agent 
d27be169-928d-44bf-b9cf-c0b66c4562f5-S0 at slave(418)@10.3.1.8:57075 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net) disconnected
I0404 08:24:10.533147  7224 master.cpp:3286] Disconnecting agent 
d27be169-928d-44bf-b9cf-c0b66c4562f5-S0 at slave(418)@10.3.1.8:57075

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-04 Thread David Forsythe 

---
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 (updated)
-

  3rdparty/CMakeLists.txt 2b63b58f7d6a88c9986b746283dcfa79b7bcb270 


Diff: https://reviews.apache.org/r/66314/diff/3/

Changes: https://reviews.apache.org/r/66314/diff/2-3/


Testing
---

make on FreeBSD


Thanks,

David Forsythe

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-04 Thread David Forsythe 


> On March 28, 2018, 8:06 a.m., Benjamin Bannier wrote:
> > 3rdparty/CMakeLists.txt
> > Lines 58-63 (patched)
> > 
> >
> > 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
> 
> 
>

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-04 Thread Benjamin Bannier 


> On März 28, 2018, 10:06 vorm., Benjamin Bannier wrote:
> > 3rdparty/CMakeLists.txt
> > Lines 58-63 (patched)
> > 
> >
> > 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

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-04 Thread Mesos Reviewbot Windows 

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



PASS: Mesos patch 66314 was successfully built and tested.

Reviews applied: `['66314']`

All the build artifacts available at: 
http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66314

- Mesos Reviewbot Windows


On April 4, 2018, 3:33 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, 3:33 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/2/
> 
> 
> Testing
> ---
> 
> make on FreeBSD
> 
> 
> Thanks,
> 
> David Forsythe
> 
>

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-03 Thread David Forsythe 

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

(Updated April 4, 2018, 3:33 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 (updated)
-

  3rdparty/CMakeLists.txt 2b63b58f7d6a88c9986b746283dcfa79b7bcb270 


Diff: https://reviews.apache.org/r/66314/diff/2/

Changes: https://reviews.apache.org/r/66314/diff/1-2/


Testing (updated)
---

make on FreeBSD


Thanks,

David Forsythe

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-03 Thread David Forsythe 


> On March 28, 2018, 8:06 a.m., Benjamin Bannier wrote:
> > 3rdparty/CMakeLists.txt
> > Lines 58-63 (patched)
> > 
> >
> > 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.

I made everything use `gmake`, but I didn't add the check/message because the 
check always succeeds. Added a TODO as discussed offline.


- David


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


On April 4, 2018, 3:33 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, 3:33 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/2/
> 
> 
> Testing
> ---
> 
> make on FreeBSD
> 
> 
> Thanks,
> 
> David Forsythe
> 
>

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-03 Thread David Forsythe 


> On March 28, 2018, 8:06 a.m., Benjamin Bannier wrote:
> > 3rdparty/CMakeLists.txt
> > Lines 58-63 (patched)
> > 
> >
> > 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()

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


---
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
> 
>

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-03 Thread Andrew Schwartzmeyer 


> On April 2, 2018, 11:42 a.m., Andrew Schwartzmeyer wrote:
> > 3rdparty/CMakeLists.txt
> > Lines 359-360 (original), 365-366 (patched)
> > 
> >
> > If I understood the above discussion correctly, I think the following 
> > would work well:
> > 
> > Use `${CMAKE_MAKE_PROGRAM}` and `${CMAKE_MAKE_PROGRAM} install` for the 
> > BUILD/INSTALL commands, instead of adding `${GNU_MAKE}`.
> > 
> > Then in the MesosConfigure.cmake, we can have a platform check `if 
> > (FREEBSD) ... make sure CMAKE_MAKE_PROGRAM is gmake` or something to that 
> > effect.
> 
> David Forsythe wrote:
> If we do that, we would be forcing gmake for the entire build, right? 
> It's not clear to me that is the best approach, since the only problem is 
> leveldb (and since newer versions of leveldb seem to use cmake?). I might 
> even be more incline to try patching LevelDBs Makefile rather than force that.
> 
> Benjamin Bannier wrote:
> @andschwa: `CMAKE_MAKE_PROGRAM` would point to whatever generator the 
> user of the cmake build selected which does not necessarily implement `make` 
> functionality (e.g., `ninja`, msvc, etc).

Oooh okay never mind me then. Its name is very misleading... I should I have 
checked docs before I spoke.


- Andrew


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


On April 2, 2018, 11:36 a.m., David Forsythe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66314/
> ---
> 
> (Updated April 2, 2018, 11:36 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 
>   cmake/CompilationConfigure.cmake 64cc56ee4208afe05df0f28af5890157e4c7d82c 
> 
> 
> Diff: https://reviews.apache.org/r/66314/diff/1/
> 
> 
> Testing
> ---
> 
> cmake --build on FreeBSD
> 
> 
> Thanks,
> 
> David Forsythe
> 
>

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-03 Thread Benjamin Bannier 


> On April 2, 2018, 8:42 p.m., Andrew Schwartzmeyer wrote:
> > 3rdparty/CMakeLists.txt
> > Lines 359-360 (original), 365-366 (patched)
> > 
> >
> > If I understood the above discussion correctly, I think the following 
> > would work well:
> > 
> > Use `${CMAKE_MAKE_PROGRAM}` and `${CMAKE_MAKE_PROGRAM} install` for the 
> > BUILD/INSTALL commands, instead of adding `${GNU_MAKE}`.
> > 
> > Then in the MesosConfigure.cmake, we can have a platform check `if 
> > (FREEBSD) ... make sure CMAKE_MAKE_PROGRAM is gmake` or something to that 
> > effect.
> 
> David Forsythe wrote:
> If we do that, we would be forcing gmake for the entire build, right? 
> It's not clear to me that is the best approach, since the only problem is 
> leveldb (and since newer versions of leveldb seem to use cmake?). I might 
> even be more incline to try patching LevelDBs Makefile rather than force that.

@andschwa: `CMAKE_MAKE_PROGRAM` would point to whatever generator the user of 
the cmake build selected which does not necessarily implement `make` 
functionality (e.g., `ninja`, msvc, etc).


- Benjamin


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


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
> 
>

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-03 Thread Benjamin Bannier 


> On March 28, 2018, 10:06 a.m., Benjamin Bannier wrote:
> > 3rdparty/CMakeLists.txt
> > Lines 58-63 (patched)
> > 
> >
> > 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
> 
>

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-02 Thread David Forsythe 


> On April 2, 2018, 6:42 p.m., Andrew Schwartzmeyer wrote:
> > 3rdparty/CMakeLists.txt
> > Lines 359-360 (original), 365-366 (patched)
> > 
> >
> > If I understood the above discussion correctly, I think the following 
> > would work well:
> > 
> > Use `${CMAKE_MAKE_PROGRAM}` and `${CMAKE_MAKE_PROGRAM} install` for the 
> > BUILD/INSTALL commands, instead of adding `${GNU_MAKE}`.
> > 
> > Then in the MesosConfigure.cmake, we can have a platform check `if 
> > (FREEBSD) ... make sure CMAKE_MAKE_PROGRAM is gmake` or something to that 
> > effect.

If we do that, we would be forcing gmake for the entire build, right? It's not 
clear to me that is the best approach, since the only problem is leveldb (and 
since newer versions of leveldb seem to use cmake?). I might even be more 
incline to try patching LevelDBs Makefile rather than force that.


- David


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


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
> 
>

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-02 Thread David Forsythe 


> On March 28, 2018, 8:06 a.m., Benjamin Bannier wrote:
> > 3rdparty/CMakeLists.txt
> > Lines 58-63 (patched)
> > 
> >
> > 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
> 
>

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-04-02 Thread Andrew Schwartzmeyer 

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




3rdparty/CMakeLists.txt
Lines 359-360 (original), 365-366 (patched)


If I understood the above discussion correctly, I think the following would 
work well:

Use `${CMAKE_MAKE_PROGRAM}` and `${CMAKE_MAKE_PROGRAM} install` for the 
BUILD/INSTALL commands, instead of adding `${GNU_MAKE}`.

Then in the MesosConfigure.cmake, we can have a platform check `if 
(FREEBSD) ... make sure CMAKE_MAKE_PROGRAM is gmake` or something to that 
effect.


- Andrew Schwartzmeyer


On April 2, 2018, 11:36 a.m., David Forsythe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66314/
> ---
> 
> (Updated April 2, 2018, 11:36 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 
>   cmake/CompilationConfigure.cmake 64cc56ee4208afe05df0f28af5890157e4c7d82c 
> 
> 
> Diff: https://reviews.apache.org/r/66314/diff/1/
> 
> 
> Testing
> ---
> 
> cmake --build on FreeBSD
> 
> 
> Thanks,
> 
> David Forsythe
> 
>

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-03-29 Thread David Forsythe 


> On March 28, 2018, 8:06 a.m., Benjamin Bannier wrote:
> > 3rdparty/CMakeLists.txt
> > Lines 58-63 (patched)
> > 
> >
> > 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).

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


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


On March 27, 2018, 7:10 p.m., David Forsythe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66314/
> ---
> 
> (Updated March 27, 2018, 7:10 p.m.)
> 
> 
> Review request for mesos 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
> 
>

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-03-28 Thread David Forsythe 


> On March 28, 2018, 8:06 a.m., Benjamin Bannier wrote:
> > 3rdparty/CMakeLists.txt
> > Lines 58-63 (patched)
> > 
> >
> > 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.

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


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


On March 27, 2018, 7:10 p.m., David Forsythe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66314/
> ---
> 
> (Updated March 27, 2018, 7:10 p.m.)
> 
> 
> Review request for mesos 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
> 
>

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-03-28 Thread Benjamin Bannier 

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




3rdparty/CMakeLists.txt
Lines 58-63 (patched)


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.


- Benjamin Bannier


On March 27, 2018, 9:10 p.m., David Forsythe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66314/
> ---
> 
> (Updated March 27, 2018, 9:10 p.m.)
> 
> 
> Review request for mesos 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
> 
>

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-03-27 Thread Mesos Reviewbot 

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



Patch looks great!

Reviews applied: [66314]

Passed command: export OS='ubuntu:14.04' BUILDTOOL='autotools' COMPILER='gcc' 
CONFIGURATION='--verbose --disable-libtool-wrappers' ENVIRONMENT='GLOG_v=1 
MESOS_VERBOSE=1'; ./support/docker-build.sh

- Mesos Reviewbot


On March 27, 2018, 7:10 p.m., David Forsythe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66314/
> ---
> 
> (Updated March 27, 2018, 7:10 p.m.)
> 
> 
> Review request for mesos 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
> 
>

Re: Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-03-27 Thread Mesos Reviewbot Windows 

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



FAIL: Some of the unit tests failed. Please check the relevant logs.

Reviews applied: `['66314']`

Failed command: `Start-MesosCITesting`

All the build artifacts available at: 
http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66314

Relevant logs:

- 
[mesos-tests-stdout.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66314/logs/mesos-tests-stdout.log):

```
[   OK ] Endpoint/SlaveEndpointTest.NoAuthorizer/2 (101 ms)
[--] 9 tests from Endpoint/SlaveEndpointTest (994 ms total)

[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0 (32 
ms)
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1 (36 
ms)
[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest (70 ms 
total)

[--] 1 test from IsolationFlag/CpuIsolatorTest
[ RUN  ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0
[   OK ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0 (813 ms)
[--] 1 test from IsolationFlag/CpuIsolatorTest (841 ms total)

[--] 1 test from IsolationFlag/MemoryIsolatorTest
[ RUN  ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0
[   OK ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0 (725 ms)
[--] 1 test from IsolationFlag/MemoryIsolatorTest (752 ms total)

[--] Global test environment tear-down
[==] 949 tests from 94 test cases ran. (417969 ms total)
[  PASSED  ] 948 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] CommandExecutorCheckTest.CommandCheckTimeout

 1 FAILED TEST
  YOU HAVE 214 DISABLED TESTS

```

- 
[mesos-tests-stderr.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66314/logs/mesos-tests-stderr.log):

```
I0327 21:51:35.280153 11208 master.cpp:10446] Updating the state of task 
730f23b7-015e-4282-9c84-44c1626d6675 of framework 
368c5872-5c09-420e-8442-a9c9bd2b6ae5- (latest state: TASK_KILLED, status 
update state: TASK_KILLED)
I0327 21:51:35.281184 14524 slave.cpp:3873] Shutting down framework 
368c5872-5c09-420e-8442-a9c9bd2b6ae5-
I0327 21:51:35.281184 14524 slave.cpp:6566] Shutting down executor 
'730f23b7-015e-4282-9c84-44c1626d6675' of framework 
368c5872-5c09-420e-8442-a9c9bd2b6ae5- at executor(1)@10.3.1.8:63953
I0327 21:51:35.28218932 slave.cpp:919] Agent terminating
W0327 21:51:35.28218932 slave.cpp:3869] Ignoring shutdown framework 
368c5872-5c09-420e-8442-a9c9bd2b6ae5- because it is teI0327 21:51:35.103152 
13644 exec.cpp:162] Version: 1.6.0
I0327 21:51:35.135192 15492 exec.cpp:236] Executor registered on agent 
368c5872-5c09-420e-8442-a9c9bd2b6ae5-S0
I0327 21:51:35.139149  6088 executor.cpp:176] Received SUBSCRIBED event
I0327 21:51:35.144176  6088 executor.cpp:180] Subscribed executor on 
winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net
I0327 21:51:35.144176  6088 executor.cpp:176] Received LAUNCH event
I0327 21:51:35.150198  6088 executor.cpp:648] Starting task 
730f23b7-015e-4282-9c84-44c1626d6675
I0327 21:51:35.239214  6088 executor.cpp:483] Running 
'D:\DCOS\mesos\src\mesos-containerizer.exe launch '
I0327 21:51:35.252205  6088 executor.cpp:661] Forked command at 5816
I0327 21:51:35.283177 10168 exec.cpp:445] Executor asked to shutdown
I0327 21:51:35.283177 15792 executor.cpp:176] Received SHUTDOWN event
I0327 21:51:35.283177 15792 executor.cpp:758] Shutting down
I0327 21:51:35.283177 15792 executor.cpp:868] Sending SIGTERM to process tree 
at pid 5rminating
I0327 21:51:35.283177 11208 master.cpp:10545] Removing task 
730f23b7-015e-4282-9c84-44c1626d6675 with resources cpus(allocated: *):4; 
mem(allocated: *):2048; disk(allocated: *):1024; ports(allocated: 
*):[31000-32000] of framework 368c5872-5c09-420e-8442-a9c9bd2b6ae5- on 
agent 368c5872-5c09-420e-8442-a9c9bd2b6ae5-S0 at slave(418)@10.3.1.8:63932 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net)
I0327 21:51:35.286193 11208 master.cpp:1295] Agent 
368c5872-5c09-420e-8442-a9c9bd2b6ae5-S0 at slave(418)@10.3.1.8:63932 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net) disconnected
I0327 21:51:35.286193 11208 master.cpp:3283] Disconnecting agent 
368c5872-5c09-420e-8442-a9c9bd2b6ae5-S0 at slave(418)@10.3.1.8:63932 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net)
I0327 21:51:35.286193 11208 master.cpp:3302] Deactivating agent 
368c5872-5c09-420e-8442-a9c9bd2b6ae5-S0 at slave(418)@10.3.1.8:63932 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net)
I0327 21:51:35.286193 13976 containerizer.cpp:2338]

Review Request 66314: Fix 3rdparty build commands for FreeBSD.

2018-03-27 Thread David Forsythe 

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

Review request for mesos.


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