For the time being we're planning on adding a new test container that
will just use CMake and will run make check. Later, when we get to a
point where all the tests are being picked up by CMake, we will follow
your advice to make sure that CMake and autotools do not diverge.
Cheers,
Artem.
On Tue
Automation is always nice, but I think this is one of those cases where there’s
not solution beyond updating guidelines and trusting the reviewers.
I recently faced another case of modifying a Makefile.am which didn’t need to
update a CMakeLists.txt. If you add a stout test file, it needs to be
I'm thinking about how we can automate the process so we do not have a
dependecy on a single human. I think if the build bot can run the test
suite for both makefile and cmakelists and compare the outcome, this should
suffice.
On 4 Oct 2015 6:50 pm, "Alex Clemmer" wrote:
> I like the idea, but so
Cool!
On Oct 5, 2015 10:38 PM, "Alex Clemmer" wrote:
> Another update, as of this weekend, we've checked in CMake changes
> that will allow you to build a pretty wide swath of the master!
>
> You can try it for yourself:
>
> ```
> mkdir build && cd build
> cmake .. && make -j 8
> ```
>
> On Sun,
Another update, as of this weekend, we've checked in CMake changes
that will allow you to build a pretty wide swath of the master!
You can try it for yourself:
```
mkdir build && cd build
cmake .. && make -j 8
```
On Sun, Oct 4, 2015 at 9:50 AM, Alex Clemmer
wrote:
> I like the idea, but someti
I like the idea, but sometimes it's not actually true that you want to
touch a CMakeLists when you touch a makefile.am. For example, headers
dependencies are automatically generated by CMake, so you don't have
to list the .hpp files. If you were only adding an hpp file to stout,
so this technique w
Can we extend a pre-commit hook in a way that it's not allowed to modify
makefile.am without touching CMakeLists and that any new file should
trigger touching CMakeLists? I think this can be part of reveiw r/38827.
On Tue, Sep 29, 2015 at 6:46 PM, Alex Clemmer
wrote:
> Just as an update, we have
Just as an update, we have expanded support for building the agent,
and there is a review up[1] to support a large part of the master.
The work is still anchored to the Windows work, so we expect the rest
of the CMake solution to materialize sporadically until the
November/December timeframe. In t
[... weeks later ...]
Alex, I think that's a great idea, actually! The module you have
implemented is not a bad start. I've put it in a JIRA ticket so I
don't lose track of it[1].
Also, just so we're clear: I'm not an expert at CMake. I wish I were,
it would have made this whole thing much easier
One related thing I have started to work on but have never polished is
FindMesos CMake script. The prototype lives here:
https://github.com/rukletsov/mesos-modules/blob/master/cmake-modules/FindMesos.cmake
My original idea was to support not only system Mesos, but also custom
builds, so that write
Yes, CMake is currently checking if the -std=c++11 flag exists. CMake
3 supports the autotools-style "feature check" style (which would be
more appropriate on platforms like Windows, anyway) but it's not clear
how far back we want to support just yet -- right now we support back
to 2.8.
One thing
> On Jul 23, 2015, at 12:40 PM, Alex Clemmer
> wrote:
>
> A fix is up for review here[1]. Thanks again for your feedback, this
> is very valuable!
>
> [1] https://reviews.apache.org/r/36743/
AFAICT this just checks whether the -std=c++11 compiler option is accepted. The
equivalent autoconf m
Cool, hoping that we also explore speeding up the tests by running them in
parallel (although I realize that automake already has a parallel test
runner).
On Wed, Jul 22, 2015 at 2:12 PM, Alex Clemmer
wrote:
> Hey folks.
>
> For some time there has been vestigial interest in a CMake[1]-based
> a
A fix is up for review here[1]. Thanks again for your feedback, this
is very valuable!
[1] https://reviews.apache.org/r/36743/
On Thu, Jul 23, 2015 at 12:18 PM, Vinod Kone wrote:
> yup.
>
> checking for C++ compiler version... 4.1.2
>
> checking for C++ compiler vendor... (cached) gnu
>
> config
yup.
checking for C++ compiler version... 4.1.2
checking for C++ compiler vendor... (cached) gnu
configure: error: GCC 4.8 or higher required (found 4.1.2)
[vinod@smfd-atr-11-sr1 build-cmake]$ echo $?
1
On Thu, Jul 23, 2015 at 12:17 PM, Alex Clemmer
wrote:
> We can easily change that to be
We can easily change that to be a FATAL_ERROR or a WARNING. I
recommend being at parity with autotools -- am I correct in assuming
that it errors out?
On Thu, Jul 23, 2015 at 12:12 PM, Vinod Kone wrote:
> The one thing I found odd while testing was that some errors when running
> 'cmake' do not r
The one thing I found odd while testing was that some errors when running
'cmake' do not result in a non-zero exit status.
For example, when I tested with an older version of GCC it gave a warning
about C++11 not being supported but went ahead otherwise.
-- Performing Test COMPILER_SUPPORTS_CXX11
I've put up a pair of fixes, tested on OS X 10.10. They are here:
(1) https://reviews.apache.org/r/36740/
(2) https://reviews.apache.org/r/36741/
This should resolve the issues, and thanks again for the bug report.
On Thu, Jul 23, 2015 at 3:32 AM, haosdent wrote:
> Sure, I use OS X 10.10. Seems
Sure, I use OS X 10.10. Seems OS X don't have librt, don't add rt when the
operate system is OSX?
On Thu, Jul 23, 2015 at 6:22 PM, Alex Clemmer
wrote:
> Thanks for reporting the issue! I appreciate it.
>
> This code is trying to find librt, which provides the POSIX.1b
> Realtime Extension (i.e.,
Thanks for reporting the issue! I appreciate it.
This code is trying to find librt, which provides the POSIX.1b
Realtime Extension (i.e., things like message passing, async I/O,
mmap'd files, etc.). Assuming you're running some flavor of Linux,
this _should_ exist on your system already, and `find
Hi, @Alex Clemmer I try to build it on OS X 10.10
```
mkdir build-cmake
cmake ..
make
```
But have this error:
```
CMake Error: The following variables are used in this project, but they are
set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake
files:
LIBRT
This is really cool!
Eclipse CDT is becoming a bit tiresome to use, but JetLabs' CLion only
support cmake, so I definitely have a stake in this working :)
Please keep us posted on progress, I'll definitely try and give it a spin
on Ubuntu and OSX.
Thanks for doing it!
*Marco Massenzio*
*Distribut
cool!
On Thu, Jul 23, 2015 at 10:03 AM, Alex Clemmer
wrote:
> Yep! We sure do:
>
> (1) https://issues.apache.org/jira/browse/MESOS-3098
> (2) https://issues.apache.org/jira/browse/MESOS-3097
> (3) https://issues.apache.org/jira/browse/MESOS-3102
>
> On Wed, Jul 22, 2015 at 6:56 PM, haosdent wro
Yep! We sure do:
(1) https://issues.apache.org/jira/browse/MESOS-3098
(2) https://issues.apache.org/jira/browse/MESOS-3097
(3) https://issues.apache.org/jira/browse/MESOS-3102
On Wed, Jul 22, 2015 at 6:56 PM, haosdent wrote:
> do we have any tickets to record support Windows?
> On Jul 23, 2015 9
do we have any tickets to record support Windows?
On Jul 23, 2015 9:50 AM, "haosdent" wrote:
> cool!
> On Jul 23, 2015 5:12 AM, "Alex Clemmer"
> wrote:
>
>> Hey folks.
>>
>> For some time there has been vestigial interest in a CMake[1]-based
>> alternative to the autotools-based build system tha
cool!
On Jul 23, 2015 5:12 AM, "Alex Clemmer" wrote:
> Hey folks.
>
> For some time there has been vestigial interest in a CMake[1]-based
> alternative to the autotools-based build system that Mesos currently
> depends on (cf. MESOS-898[2]). In the near future we expect to start
> thinking about
On Wed, Jul 22, 2015 at 3:47 PM, Vinod Kone wrote:
> This is exciting! Thanks for sharing the progress Alex.
>
> Mind sending us instructions on how to build/test with cmake for noobs like
> me?
Ah, rats, I knew I was forgetting something.
It actually looks pretty much like the autotools build s
This is exciting! Thanks for sharing the progress Alex.
Mind sending us instructions on how to build/test with cmake for noobs like
me?
On Wed, Jul 22, 2015 at 2:19 PM, Kevin Lyda wrote:
> On Wed, Jul 22, 2015 at 10:12 PM, Alex Clemmer
> wrote:
> > depends on (cf. MESOS-898[2]). In the near fu
On Wed, Jul 22, 2015 at 10:12 PM, Alex Clemmer
wrote:
> depends on (cf. MESOS-898[2]). In the near future we expect to start
> thinking about supporting little-known platforms such as "Windows",
> (where a fully cross-platform build system is table stakes).
Uh... why? More importantly a lot of pr
Hey folks.
For some time there has been vestigial interest in a CMake[1]-based
alternative to the autotools-based build system that Mesos currently
depends on (cf. MESOS-898[2]). In the near future we expect to start
thinking about supporting little-known platforms such as "Windows",
(where a full
30 matches
Mail list logo
