[jira] [Commented] (ZOOKEEPER-2844) Zookeeper auto purge process does not purge files
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622374#comment-16622374 ] Andrew Schwartzmeyer commented on ZOOKEEPER-2844: - Sorry [~maoling] I haven't a clue :( If I had to hazard a guess, deleting files (like purging is trying to do) often fails on Windows because you can't do it if there is any handle open to said file. If I were debugging it, that's what I would look for. > Zookeeper auto purge process does not purge files > - > > Key: ZOOKEEPER-2844 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2844 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.6 > Environment: Windows Server 2008 R2 >Reporter: Avi Steiner >Priority: Major > Attachments: ZK.zip > > > I'm using Zookeeper 3.4.6 > > The ZK log data folder keeps growing with transaction logs files (log.*). > > I set the following in zoo.cfg: > autopurge.purgeInterval=1 > autopurge.snapRetainCount=3 > dataDir=..\\data > > Per ZK log, it reads those parameters: > > 2017-07-13 10:36:21,266 [myid:] - INFO [main:DatadirCleanupManager@78] - > autopurge.snapRetainCount set to 3 > 2017-07-13 10:36:21,266 [myid:] - INFO [main:DatadirCleanupManager@79] - > autopurge.purgeInterval set to 1 > > It also says that cleanup process is running: > > 2017-07-13 10:36:21,266 [myid:] - INFO > [PurgeTask:DatadirCleanupManager$PurgeTask@138] - Purge task started. > 2017-07-13 10:36:21,297 [myid:] - INFO > [PurgeTask:DatadirCleanupManager$PurgeTask@144] - Purge task completed. > > But actually nothing is deleted. > Every service restart, a new file is created. > > The only parameter I managed to change is preAllocSize, which means the > minimum size per file. The default is 64MB. I changed it to 10KB only for > testing, and I swa the effect as expected: new files were created with 10KB. > I also tried to create a batch file that will run the following: > java -cp > zookeeper-3.4.6.jar;lib/slf4j-api-1.6.1.jar;lib/slf4j-log4j12-1.6.1.jar;lib/log4j-1.2.16.jar;conf > org.apache.zookeeper.server.PurgeTxnLog .\data -n 3 > But it still doesn't do the job. > Please advise. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3025) cmake windows build is broken on jenkins
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449109#comment-16449109
]
Andrew Schwartzmeyer commented on ZOOKEEPER-3025:
-
No problem [~phunt]! I am very glad to see a working Windows CI system :D
> cmake windows build is broken on jenkins
>
>
> Key: ZOOKEEPER-3025
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3025
> Project: ZooKeeper
> Issue Type: Bug
> Components: build
>Affects Versions: 3.5.4, 3.6.0
>Reporter: Patrick Hunt
>Assignee: Andrew Schwartzmeyer
>Priority: Blocker
> Fix For: 3.5.4, 3.6.0
>
>
> Jenkins build for windows cmake is failing:
> started here:
> [https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk-windows-cmake/2717/console]
> {noformat}
> f:\jenkins\jenkins-slave\workspace\zookeeper-trunk-windows-cmake\src\c\src\hashtable\hashtable.h(6):
> fatal error C1083: Cannot open include file: 'winconfig.h': No such file or
> directory
> [F:\jenkins\jenkins-slave\workspace\ZooKeeper-trunk-windows-cmake\src\c\hashtable.vcxproj]
> hashtable.c{noformat}
>
> Looks like one or the other or both of these commits are at issue (jenkins
> build broken on these two changes being committed)
> h2. [#2717 (Apr 16, 2018 4:58:17
> AM)|https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk-windows-cmake/2717/changes]
> # ZOOKEEPER-3017: Link libm in CMake on FreeBSD. —
> [hanm|https://builds.apache.org/user/hanm/] /
> [detail|https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk-windows-cmake/2717/changes#67378512285c4b8dc9be50b90bbd2967068fc24e]
> # ZOOKEEPER-2999: CMake build should use target-level commands —
> [hanm|https://builds.apache.org/user/hanm/] /
> [detail|https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk-windows-cmake/2717/changes#9ba4aeb4f92c1fc3167ff8e2b56e02f3e344d3ba]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (ZOOKEEPER-3025) cmake windows build is broken on jenkins
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Schwartzmeyer reassigned ZOOKEEPER-3025:
---
Assignee: Andrew Schwartzmeyer (was: Michael Han)
> cmake windows build is broken on jenkins
>
>
> Key: ZOOKEEPER-3025
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3025
> Project: ZooKeeper
> Issue Type: Bug
> Components: build
>Affects Versions: 3.5.4, 3.6.0
>Reporter: Patrick Hunt
>Assignee: Andrew Schwartzmeyer
>Priority: Blocker
> Fix For: 3.5.4, 3.6.0
>
>
> Jenkins build for windows cmake is failing:
> started here:
> [https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk-windows-cmake/2717/console]
> {noformat}
> f:\jenkins\jenkins-slave\workspace\zookeeper-trunk-windows-cmake\src\c\src\hashtable\hashtable.h(6):
> fatal error C1083: Cannot open include file: 'winconfig.h': No such file or
> directory
> [F:\jenkins\jenkins-slave\workspace\ZooKeeper-trunk-windows-cmake\src\c\hashtable.vcxproj]
> hashtable.c{noformat}
>
> Looks like one or the other or both of these commits are at issue (jenkins
> build broken on these two changes being committed)
> h2. [#2717 (Apr 16, 2018 4:58:17
> AM)|https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk-windows-cmake/2717/changes]
> # ZOOKEEPER-3017: Link libm in CMake on FreeBSD. —
> [hanm|https://builds.apache.org/user/hanm/] /
> [detail|https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk-windows-cmake/2717/changes#67378512285c4b8dc9be50b90bbd2967068fc24e]
> # ZOOKEEPER-2999: CMake build should use target-level commands —
> [hanm|https://builds.apache.org/user/hanm/] /
> [detail|https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk-windows-cmake/2717/changes#9ba4aeb4f92c1fc3167ff8e2b56e02f3e344d3ba]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3025) cmake windows build is broken on jenkins
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449039#comment-16449039
]
Andrew Schwartzmeyer commented on ZOOKEEPER-3025:
-
Ah, my bad. Turns out to be caused by
[https://github.com/apache/zookeeper/pull/486/commits/b030f29c02bd87f10c0ac995f4c8abf85eb7bf9b]
We'd tested on Linux, but not Windows, which has an extra include file. Writing
a patch currently.
> cmake windows build is broken on jenkins
>
>
> Key: ZOOKEEPER-3025
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3025
> Project: ZooKeeper
> Issue Type: Bug
> Components: build
>Affects Versions: 3.5.4, 3.6.0
>Reporter: Patrick Hunt
>Assignee: Michael Han
>Priority: Blocker
> Fix For: 3.5.4, 3.6.0
>
>
> Jenkins build for windows cmake is failing:
> started here:
> [https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk-windows-cmake/2717/console]
> {noformat}
> f:\jenkins\jenkins-slave\workspace\zookeeper-trunk-windows-cmake\src\c\src\hashtable\hashtable.h(6):
> fatal error C1083: Cannot open include file: 'winconfig.h': No such file or
> directory
> [F:\jenkins\jenkins-slave\workspace\ZooKeeper-trunk-windows-cmake\src\c\hashtable.vcxproj]
> hashtable.c{noformat}
>
> Looks like one or the other or both of these commits are at issue (jenkins
> build broken on these two changes being committed)
> h2. [#2717 (Apr 16, 2018 4:58:17
> AM)|https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk-windows-cmake/2717/changes]
> # ZOOKEEPER-3017: Link libm in CMake on FreeBSD. —
> [hanm|https://builds.apache.org/user/hanm/] /
> [detail|https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk-windows-cmake/2717/changes#67378512285c4b8dc9be50b90bbd2967068fc24e]
> # ZOOKEEPER-2999: CMake build should use target-level commands —
> [hanm|https://builds.apache.org/user/hanm/] /
> [detail|https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk-windows-cmake/2717/changes#9ba4aeb4f92c1fc3167ff8e2b56e02f3e344d3ba]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-2999) CMake build should use target-level commands
Andrew Schwartzmeyer created ZOOKEEPER-2999:
---
Summary: CMake build should use target-level commands
Key: ZOOKEEPER-2999
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2999
Project: ZooKeeper
Issue Type: Improvement
Affects Versions: 3.6.0
Reporter: Andrew Schwartzmeyer
Assignee: Andrew Schwartzmeyer
Originally suggested in [GitHub PR
#386|https://github.com/apache/zookeeper/pull/386], the CMake build I wrote
used {{include_directories}}, which has global side effects, instead of the
more explicit {{target_include_directories}}, to include directories per target
(and with private or public scoping).
Furthermore, it should also use {{CMAKE_CURRENT_SOURCE_DIR}} over
{{CMAKE_SOURCE_DIR}} in order to allow inclusion in other projects via
{{add_subdirectory()}}, and we can reduce the minimally required CMake version
to 3.5 from 3.6.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2998) CMake declares incorrect ZooKeeper version
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Schwartzmeyer updated ZOOKEEPER-2998:
Summary: CMake declares incorrect ZooKeeper version (was: CMake declares
incorrect ZooKeepeer version)
> CMake declares incorrect ZooKeeper version
> --
>
> Key: ZOOKEEPER-2998
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2998
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: Andrew Schwartzmeyer
>Assignee: Andrew Schwartzmeyer
>Priority: Major
>
> The \{{CMakeLists.txt}} file in the master branch declares version 3.5.3
> instead of 3.6.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2998) CMake declares incorrect ZooKeeper version
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Schwartzmeyer updated ZOOKEEPER-2998:
Priority: Minor (was: Major)
> CMake declares incorrect ZooKeeper version
> --
>
> Key: ZOOKEEPER-2998
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2998
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: Andrew Schwartzmeyer
>Assignee: Andrew Schwartzmeyer
>Priority: Minor
>
> The \{{CMakeLists.txt}} file in the master branch declares version 3.5.3
> instead of 3.6.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2998) CMake declares incorrect ZooKeepeer version
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Schwartzmeyer updated ZOOKEEPER-2998:
Summary: CMake declares incorrect ZooKeepeer version (was: CMake declares
old version)
> CMake declares incorrect ZooKeepeer version
> ---
>
> Key: ZOOKEEPER-2998
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2998
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: Andrew Schwartzmeyer
>Assignee: Andrew Schwartzmeyer
>Priority: Major
>
> The \{{CMakeLists.txt}} file in the master branch declares version 3.5.3
> instead of 3.6.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-2998) CMake declares old version
Andrew Schwartzmeyer created ZOOKEEPER-2998:
---
Summary: CMake declares old version
Key: ZOOKEEPER-2998
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2998
Project: ZooKeeper
Issue Type: Bug
Affects Versions: 3.6.0
Reporter: Andrew Schwartzmeyer
Assignee: Andrew Schwartzmeyer
The \{{CMakeLists.txt}} file in the master branch declares version 3.5.3
instead of 3.6.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-2997) CMake should not force static CRT linking
Andrew Schwartzmeyer created ZOOKEEPER-2997:
---
Summary: CMake should not force static CRT linking
Key: ZOOKEEPER-2997
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2997
Project: ZooKeeper
Issue Type: Bug
Environment: Windows
Reporter: Andrew Schwartzmeyer
Assignee: Andrew Schwartzmeyer
When writing the CMake build, I erroneously forced ZooKeeper to link to the
Windows CRT statically. Instead of setting this, we should rely on CMake's
defaults, and let users override it if they choose to by configuring with
setting {{CMAKE_CXX_ARGS}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-2905) Don't include `config.h` in `zookeeper.h`
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179917#comment-16179917
]
Andrew Schwartzmeyer commented on ZOOKEEPER-2905:
-
I didn't catch this sooner as the CMake build on Windows and Linux for Mesos
uses a newer version of Glog than our Autotools build, which doesn't have this
bug. So it was when my ZooKeeper patch with the bug was combined with an old
version of Glog (0.3.3) which also had the bug, that I finally found it.
> Don't include `config.h` in `zookeeper.h`
> -
>
> Key: ZOOKEEPER-2905
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2905
> Project: ZooKeeper
> Issue Type: Bug
> Environment: Linux-ish environments.
>Reporter: Andrew Schwartzmeyer
>Assignee: Andrew Schwartzmeyer
>
> In ZOOKEEPER-2841 I fixed the inclusion of project-specific porting changes
> that were included in the public headers, which then broke upstream projects
> (in my case, Mesos).
> Unfortunately, I inadvertently created the exact same problem for Linux (or
> really any system that uses Autotools), and it wasn't evident until the build
> was coupled with another project with the same problem. More specifically,
> when including ZooKeeper (with my changes) in Mesos, and including Google's
> Glog in Mesos, and building both with Autotools (which we also support), both
> packages define the pre-processor macro {{PACKAGE_VERSION}}, and so so
> publicly. This is defined in {{config.h}} by Autotools, and is not a problem
> _unless included publicly_.
> When refactoring, I saw two includes in {{zookeeper.h}} that instead of being
> guarded by e.g. {{#ifdef HAVE_SYS_SOCKET_H}} were guarded by {{#ifndef
> WIN32}}. Without realizing that I would create the exact same problem I was
> elsewhere fixing, I erroneously added {{#include "config.h"}} and guarded the
> includes "properly." But there is _very good reasons_ not to do this
> (explained above).
> The patch to fix this is simple:
> {noformat}
> diff --git a/src/c/include/zookeeper.h b/src/c/include/zookeeper.h
> index d20e70af4..b0bb09e3f 100644
> --- a/src/c/include/zookeeper.h
> +++ b/src/c/include/zookeeper.h
> @@ -21,13 +21,9 @@
> #include
> -#include "config.h"
> -
> -#ifdef HAVE_SYS_SOCKET_H
> +/* we must not include config.h as a public header */
> +#ifndef WIN32
> #include
> -#endif
> -
> -#ifdef HAVE_SYS_TIME_H
> #include
> #endif
> diff --git a/src/c/src/zookeeper.c b/src/c/src/zookeeper.c
> index 220c57dc4..9b837f227 100644
> --- a/src/c/src/zookeeper.c
> +++ b/src/c/src/zookeeper.c
> @@ -24,6 +24,7 @@
> #define USE_IPV6
> #endif
> +#include "config.h"
> #include
> #include
> #include
> {noformat}
> I am opening pull requests in a few minutes to have this applied to branch
> 3.4 and 3.5.
> I'm sorry!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ZOOKEEPER-2905) Don't include `config.h` in `zookeeper.h`
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Schwartzmeyer updated ZOOKEEPER-2905:
Summary: Don't include `config.h` in `zookeeper.h` (was: Don't include
"config.h" in public headers)
> Don't include `config.h` in `zookeeper.h`
> -
>
> Key: ZOOKEEPER-2905
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2905
> Project: ZooKeeper
> Issue Type: Bug
> Environment: Linux-ish environments.
>Reporter: Andrew Schwartzmeyer
>Assignee: Andrew Schwartzmeyer
>
> In ZOOKEEPER-2841 I fixed the inclusion of project-specific porting changes
> that were included in the public headers, which then broke upstream projects
> (in my case, Mesos).
> Unfortunately, I inadvertently created the exact same problem for Linux (or
> really any system that uses Autotools), and it wasn't evident until the build
> was coupled with another project with the same problem. More specifically,
> when including ZooKeeper (with my changes) in Mesos, and including Google's
> Glog in Mesos, and building both with Autotools (which we also support), both
> packages define the pre-processor macro {{PACKAGE_VERSION}}, and so so
> publicly. This is defined in {{config.h}} by Autotools, and is not a problem
> _unless included publicly_.
> When refactoring, I saw two includes in {{zookeeper.h}} that instead of being
> guarded by e.g. {{#ifdef HAVE_SYS_SOCKET_H}} were guarded by {{#ifndef
> WIN32}}. Without realizing that I would create the exact same problem I was
> elsewhere fixing, I erroneously added {{#include "config.h"}} and guarded the
> includes "properly." But there is _very good reasons_ not to do this
> (explained above).
> The patch to fix this is simple:
> {noformat}
> diff --git a/src/c/include/zookeeper.h b/src/c/include/zookeeper.h
> index d20e70af4..b0bb09e3f 100644
> --- a/src/c/include/zookeeper.h
> +++ b/src/c/include/zookeeper.h
> @@ -21,13 +21,9 @@
> #include
> -#include "config.h"
> -
> -#ifdef HAVE_SYS_SOCKET_H
> +/* we must not include config.h as a public header */
> +#ifndef WIN32
> #include
> -#endif
> -
> -#ifdef HAVE_SYS_TIME_H
> #include
> #endif
> diff --git a/src/c/src/zookeeper.c b/src/c/src/zookeeper.c
> index 220c57dc4..9b837f227 100644
> --- a/src/c/src/zookeeper.c
> +++ b/src/c/src/zookeeper.c
> @@ -24,6 +24,7 @@
> #define USE_IPV6
> #endif
> +#include "config.h"
> #include
> #include
> #include
> {noformat}
> I am opening pull requests in a few minutes to have this applied to branch
> 3.4 and 3.5.
> I'm sorry!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (ZOOKEEPER-2905) Don't include "config.h" in public headers
Andrew Schwartzmeyer created ZOOKEEPER-2905:
---
Summary: Don't include "config.h" in public headers
Key: ZOOKEEPER-2905
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2905
Project: ZooKeeper
Issue Type: Bug
Environment: Linux-ish environments.
Reporter: Andrew Schwartzmeyer
Assignee: Andrew Schwartzmeyer
In ZOOKEEPER-2841 I fixed the inclusion of project-specific porting changes
that were included in the public headers, which then broke upstream projects
(in my case, Mesos).
Unfortunately, I inadvertently created the exact same problem for Linux (or
really any system that uses Autotools), and it wasn't evident until the build
was coupled with another project with the same problem. More specifically, when
including ZooKeeper (with my changes) in Mesos, and including Google's Glog in
Mesos, and building both with Autotools (which we also support), both packages
define the pre-processor macro {{PACKAGE_VERSION}}, and so so publicly. This is
defined in {{config.h}} by Autotools, and is not a problem _unless included
publicly_.
When refactoring, I saw two includes in {{zookeeper.h}} that instead of being
guarded by e.g. {{#ifdef HAVE_SYS_SOCKET_H}} were guarded by {{#ifndef WIN32}}.
Without realizing that I would create the exact same problem I was elsewhere
fixing, I erroneously added {{#include "config.h"}} and guarded the includes
"properly." But there is _very good reasons_ not to do this (explained above).
The patch to fix this is simple:
{noformat}
diff --git a/src/c/include/zookeeper.h b/src/c/include/zookeeper.h
index d20e70af4..b0bb09e3f 100644
--- a/src/c/include/zookeeper.h
+++ b/src/c/include/zookeeper.h
@@ -21,13 +21,9 @@
#include
-#include "config.h"
-
-#ifdef HAVE_SYS_SOCKET_H
+/* we must not include config.h as a public header */
+#ifndef WIN32
#include
-#endif
-
-#ifdef HAVE_SYS_TIME_H
#include
#endif
diff --git a/src/c/src/zookeeper.c b/src/c/src/zookeeper.c
index 220c57dc4..9b837f227 100644
--- a/src/c/src/zookeeper.c
+++ b/src/c/src/zookeeper.c
@@ -24,6 +24,7 @@
#define USE_IPV6
#endif
+#include "config.h"
#include
#include
#include
{noformat}
I am opening pull requests in a few minutes to have this applied to branch 3.4
and 3.5.
I'm sorry!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ZOOKEEPER-2874) Windows Debug builds don't link with `/MTd`
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Schwartzmeyer updated ZOOKEEPER-2874:
Summary: Windows Debug builds don't link with `/MTd` (was: Windows Debug
builds don't link to /MTd)
> Windows Debug builds don't link with `/MTd`
> ---
>
> Key: ZOOKEEPER-2874
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2874
> Project: ZooKeeper
> Issue Type: Bug
> Environment: Windows 10 using CMake
>Reporter: Andrew Schwartzmeyer
>Assignee: Andrew Schwartzmeyer
>
> While not apparent when building ZooKeeper stand-alone, further testing when
> linking with Mesos revealed it was ZooKeeper that was causing the warning:
> {noformat}
> LIBCMTD.lib(initializers.obj) : warning LNK4098: defaultlib 'libcmt.lib'
> conflicts with use of other libs; use /NODEFAULTLIB:library
> [C:\Users\andschwa\src\mesos\build\src\slave\mesos-agent.vcxproj]
> {noformat}
> As Mesos is linking with {{/MTd}} in Debug configuration (which is the most
> common practice).
> Once I found the source of the warning, the fix is trivial and I am posting a
> patch.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (ZOOKEEPER-2874) Windows Debug builds don't link to /MTd
Andrew Schwartzmeyer created ZOOKEEPER-2874:
---
Summary: Windows Debug builds don't link to /MTd
Key: ZOOKEEPER-2874
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2874
Project: ZooKeeper
Issue Type: Bug
Environment: Windows 10 using CMake
Reporter: Andrew Schwartzmeyer
Assignee: Andrew Schwartzmeyer
While not apparent when building ZooKeeper stand-alone, further testing when
linking with Mesos revealed it was ZooKeeper that was causing the warning:
{noformat}
LIBCMTD.lib(initializers.obj) : warning LNK4098: defaultlib 'libcmt.lib'
conflicts with use of other libs; use /NODEFAULTLIB:library
[C:\Users\andschwa\src\mesos\build\src\slave\mesos-agent.vcxproj]
{noformat}
As Mesos is linking with {{/MTd}} in Debug configuration (which is the most
common practice).
Once I found the source of the warning, the fix is trivial and I am posting a
patch.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (ZOOKEEPER-2756) Add CMake build system for better cross-platform support
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Schwartzmeyer resolved ZOOKEEPER-2756. - Resolution: Fixed > Add CMake build system for better cross-platform support > > > Key: ZOOKEEPER-2756 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2756 > Project: ZooKeeper > Issue Type: Improvement > Components: build, c client >Affects Versions: 3.5.2 > Environment: Windows and Linux >Reporter: Andrew Schwartzmeyer >Assignee: Andrew Schwartzmeyer > Labels: build, windows > Attachments: ZOOKEEPER-2756.patch > > > The C bindings primary build system is Autotools. This obviously does not > work for Windows, and so the original port to Windows simply added a Visual > Studio solution to the project, splitting the build system. As new versions > of Visual Studio have come along, new (probably auto-converted) solutions > have come along (see zookeeper.sln vs zookeeper-vs2013.sln). When Mesos > started being ported to Windows, a Visual Studio 2015 solution was needed, > and the previous developer created yet another solution, and setup Mesos' > build to patch ZooKeeper and add the 2015 solution. Now Visual Studio 2017 > was released, and in the process of moving Mesos ahead, I realized that I > would either have to make *yet another* converted solution for ZooKeeper. So > instead I tackled the root problem, and ported the Autotools build to CMake, > which is a meta-build system which generates files for the in-use platform > (whether it be Linux or Solaris or MacOS or Windows). > NOTE: I already have this patch, and will submit it. It has a couple TODOs, > and some other things in it that were necessary for Mesos that may need to be > pulled into separate patches. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ZOOKEEPER-2859) CMake build doesn't support OS X
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102320#comment-16102320
]
Andrew Schwartzmeyer commented on ZOOKEEPER-2859:
-
Fixing the build of just the client is trivial. Change {{if(UNIX)}} to
{{if(LINUX)}} where we guard {{target_link_libraries(zookeeper PUBLIC m rt)}}.
> CMake build doesn't support OS X
>
>
> Key: ZOOKEEPER-2859
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2859
> Project: ZooKeeper
> Issue Type: Bug
> Environment: OS X 10.12.6
>Reporter: Andrew Schwartzmeyer
>Assignee: Andrew Schwartzmeyer
>
> Couple problems:
> libm, librt, and libdl are all Linux specific, and provided "for free" on OS X
> CppUnit (at least on OS X) needs `-std=c++11`
> clang's ld doesn't understand --wrap
> I can post an easy patch that at least lets you build the client (but not the
> tests). The tests use that `--wrap` and it's non trivial to fix that on OS X.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (ZOOKEEPER-2859) CMake build doesn't support OS X
Andrew Schwartzmeyer created ZOOKEEPER-2859: --- Summary: CMake build doesn't support OS X Key: ZOOKEEPER-2859 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2859 Project: ZooKeeper Issue Type: Bug Environment: OS X 10.12.6 Reporter: Andrew Schwartzmeyer Assignee: Andrew Schwartzmeyer Couple problems: libm, librt, and libdl are all Linux specific, and provided "for free" on OS X CppUnit (at least on OS X) needs `-std=c++11` clang's ld doesn't understand --wrap I can post an easy patch that at least lets you build the client (but not the tests). The tests use that `--wrap` and it's non trivial to fix that on OS X. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ZOOKEEPER-2491) C client build error in vs 2015
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Schwartzmeyer reassigned ZOOKEEPER-2491: --- Assignee: Andrew Schwartzmeyer (was: spooky000) > C client build error in vs 2015 > > > Key: ZOOKEEPER-2491 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2491 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.5.2 > Environment: windows vs 2015 >Reporter: spooky000 >Assignee: Andrew Schwartzmeyer >Priority: Minor > Fix For: 3.5.4, 3.6.0 > > Attachments: ZOOKEEPER-2491.patch, ZOOKEEPER-2491.patch, > ZOOKEEPER-2491.patch > > > Visual Studio 2015 supports snprintf. > #define snprintf _snprintf throw error. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ZOOKEEPER-2491) C client build error in vs 2015
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102060#comment-16102060 ] Andrew Schwartzmeyer commented on ZOOKEEPER-2491: - [~hanm] I believe we can close this issue; I fixed it in my patch that's upstream now for 3.5+ > C client build error in vs 2015 > > > Key: ZOOKEEPER-2491 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2491 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.5.2 > Environment: windows vs 2015 >Reporter: spooky000 >Assignee: spooky000 >Priority: Minor > Fix For: 3.5.4, 3.6.0 > > Attachments: ZOOKEEPER-2491.patch, ZOOKEEPER-2491.patch, > ZOOKEEPER-2491.patch > > > Visual Studio 2015 supports snprintf. > #define snprintf _snprintf throw error. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ZOOKEEPER-2841) ZooKeeper public include files leak porting changes
Andrew Schwartzmeyer created ZOOKEEPER-2841:
---
Summary: ZooKeeper public include files leak porting changes
Key: ZOOKEEPER-2841
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2841
Project: ZooKeeper
Issue Type: Bug
Components: c client
Environment: Windows 10 with Visual Studio 2017
Reporter: Andrew Schwartzmeyer
Assignee: Andrew Schwartzmeyer
The fundamental problem is that the port of the C client to Windows is now
close to six years old, with very few updates. This port leaks a lot of changes
that should be internal to ZooKeeper, and many of those changes are simply no
longer relevant. The correct thing to do is attempt to refactor the Windows
port for new versions of ZooKeeper, removing dead/unneeded porting code, and
moving dangerous porting code to C files instead of public headers.
Two primary examples of this problem are
[ZOOKEEPER-2491|https://issues.apache.org/jira/browse/ZOOKEEPER-2491] and
[MESOS-7541|https://issues.apache.org/jira/browse/MESOS-7541].
The first issue stems from this ancient porting code:
{noformat}
#define snprintf _snprintf
{noformat}
in
[winconfig.h|https://github.com/apache/zookeeper/blob/ddf0364903bf7ac7cd25b2e1927f0d9d3c7203c4/src/c/include/winconfig.h#L179].
Newer versions of Windows C libraries define {{snprintf}} as a function, and
so it cannot be redefined.
The second issue comes from this undocumented change:
{noformat}
#undef AF_INET6
{noformat}
again in
[winconfig.h|https://github.com/apache/zookeeper/blob/ddf0364903bf7ac7cd25b2e1927f0d9d3c7203c4/src/c/include/winconfig.h#L169]
which breaks any library that uses IPv6 and {{winsock2.h}}.
Furthermore, the inclusion of the following defines and headers causes terrible
problems for consuming libraries, as they leak into ZooKeeper's public headers:
{noformat}
#define _CRT_SECURE_NO_WARNINGS
#define WIN32_LEAN_AND_MEAN
#include
#include
#include
#include
#include
{noformat}
Depending on the order that a project includes or compiles files, this may or
may not cause {{WIN32_LEAN_AND_MEAN}} to become unexpectedly defined, and
{{windows.h}} to be unexpectedly included. This problem is exacberated by the
fact that the {{winsock2.h}} and {{windows.h}} headers are order-dependent (if
you read up on this, you'll see that defining {{WIN32_LEAN_AND_MEAN}} was meant
to work-around this).
Going forward, porting changes should live next to where they are used,
preferably in source files, not header files, so they remain contained.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ZOOKEEPER-2756) Add CMake build system for better cross-platform support
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16044747#comment-16044747 ] Andrew Schwartzmeyer commented on ZOOKEEPER-2756: - Automated tests appear all good now, and the license headers were added. > Add CMake build system for better cross-platform support > > > Key: ZOOKEEPER-2756 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2756 > Project: ZooKeeper > Issue Type: Improvement > Components: build, c client >Affects Versions: 3.5.2 > Environment: Windows and Linux >Reporter: Andrew Schwartzmeyer >Assignee: Andrew Schwartzmeyer > Labels: build, windows > Attachments: ZOOKEEPER-2756.patch > > > The C bindings primary build system is Autotools. This obviously does not > work for Windows, and so the original port to Windows simply added a Visual > Studio solution to the project, splitting the build system. As new versions > of Visual Studio have come along, new (probably auto-converted) solutions > have come along (see zookeeper.sln vs zookeeper-vs2013.sln). When Mesos > started being ported to Windows, a Visual Studio 2015 solution was needed, > and the previous developer created yet another solution, and setup Mesos' > build to patch ZooKeeper and add the 2015 solution. Now Visual Studio 2017 > was released, and in the process of moving Mesos ahead, I realized that I > would either have to make *yet another* converted solution for ZooKeeper. So > instead I tackled the root problem, and ported the Autotools build to CMake, > which is a meta-build system which generates files for the in-use platform > (whether it be Linux or Solaris or MacOS or Windows). > NOTE: I already have this patch, and will submit it. It has a couple TODOs, > and some other things in it that were necessary for Mesos that may need to be > pulled into separate patches. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ZOOKEEPER-2756) Add CMake build system for better cross-platform support
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16030213#comment-16030213 ] Andrew Schwartzmeyer commented on ZOOKEEPER-2756: - `git rm`'d the old VS solutions. > Add CMake build system for better cross-platform support > > > Key: ZOOKEEPER-2756 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2756 > Project: ZooKeeper > Issue Type: Improvement > Components: build, c client >Affects Versions: 3.5.2 > Environment: Windows and Linux >Reporter: Andrew Schwartzmeyer >Assignee: Andrew Schwartzmeyer > Labels: build, windows > Attachments: ZOOKEEPER-2756.patch > > > The C bindings primary build system is Autotools. This obviously does not > work for Windows, and so the original port to Windows simply added a Visual > Studio solution to the project, splitting the build system. As new versions > of Visual Studio have come along, new (probably auto-converted) solutions > have come along (see zookeeper.sln vs zookeeper-vs2013.sln). When Mesos > started being ported to Windows, a Visual Studio 2015 solution was needed, > and the previous developer created yet another solution, and setup Mesos' > build to patch ZooKeeper and add the 2015 solution. Now Visual Studio 2017 > was released, and in the process of moving Mesos ahead, I realized that I > would either have to make *yet another* converted solution for ZooKeeper. So > instead I tackled the root problem, and ported the Autotools build to CMake, > which is a meta-build system which generates files for the in-use platform > (whether it be Linux or Solaris or MacOS or Windows). > NOTE: I already have this patch, and will submit it. It has a couple TODOs, > and some other things in it that were necessary for Mesos that may need to be > pulled into separate patches. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ZOOKEEPER-2756) Add CMake build system for better cross-platform support
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025219#comment-16025219 ] Andrew Schwartzmeyer commented on ZOOKEEPER-2756: - @hanm Oh no, the GitHub comments are only one way! And it doesn't preserve the automatic links. I'll update the PR and include the deletion of the deprecated files :) This is the commit I was referring to: https://github.com/apache/zookeeper/commit/065056b0b240b7bdff2eebe41db86a9a3ea6ecfc; it's not in the tree, it's just on a branch in my repo. > Add CMake build system for better cross-platform support > > > Key: ZOOKEEPER-2756 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2756 > Project: ZooKeeper > Issue Type: Improvement > Components: build, c client >Affects Versions: 3.5.2 > Environment: Windows and Linux >Reporter: Andrew Schwartzmeyer >Assignee: Andrew Schwartzmeyer > Labels: build, windows > Attachments: ZOOKEEPER-2756.patch > > > The C bindings primary build system is Autotools. This obviously does not > work for Windows, and so the original port to Windows simply added a Visual > Studio solution to the project, splitting the build system. As new versions > of Visual Studio have come along, new (probably auto-converted) solutions > have come along (see zookeeper.sln vs zookeeper-vs2013.sln). When Mesos > started being ported to Windows, a Visual Studio 2015 solution was needed, > and the previous developer created yet another solution, and setup Mesos' > build to patch ZooKeeper and add the 2015 solution. Now Visual Studio 2017 > was released, and in the process of moving Mesos ahead, I realized that I > would either have to make *yet another* converted solution for ZooKeeper. So > instead I tackled the root problem, and ported the Autotools build to CMake, > which is a meta-build system which generates files for the in-use platform > (whether it be Linux or Solaris or MacOS or Windows). > NOTE: I already have this patch, and will submit it. It has a couple TODOs, > and some other things in it that were necessary for Mesos that may need to be > pulled into separate patches. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ZOOKEEPER-2756) Add CMake build system for better cross-platform support
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975238#comment-15975238 ] Andrew Schwartzmeyer commented on ZOOKEEPER-2756: - Ah, yes, I can do that Michael! Just a note: the HowToContribute docs specifically still say to attach a patch like a did here, and that PR support is experimental. Trust me, I am happy to open a PR instead :D, just wanted to point out why I went with a patch originally. > Add CMake build system for better cross-platform support > > > Key: ZOOKEEPER-2756 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2756 > Project: ZooKeeper > Issue Type: Improvement > Components: build, c client >Affects Versions: 3.5.2 > Environment: Windows and Linux >Reporter: Andrew Schwartzmeyer >Assignee: Andrew Schwartzmeyer > Labels: build, windows > Attachments: ZOOKEEPER-2756.patch > > > The C bindings primary build system is Autotools. This obviously does not > work for Windows, and so the original port to Windows simply added a Visual > Studio solution to the project, splitting the build system. As new versions > of Visual Studio have come along, new (probably auto-converted) solutions > have come along (see zookeeper.sln vs zookeeper-vs2013.sln). When Mesos > started being ported to Windows, a Visual Studio 2015 solution was needed, > and the previous developer created yet another solution, and setup Mesos' > build to patch ZooKeeper and add the 2015 solution. Now Visual Studio 2017 > was released, and in the process of moving Mesos ahead, I realized that I > would either have to make *yet another* converted solution for ZooKeeper. So > instead I tackled the root problem, and ported the Autotools build to CMake, > which is a meta-build system which generates files for the in-use platform > (whether it be Linux or Solaris or MacOS or Windows). > NOTE: I already have this patch, and will submit it. It has a couple TODOs, > and some other things in it that were necessary for Mesos that may need to be > pulled into separate patches. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ZOOKEEPER-2756) Add CMake build system for better cross-platform support
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15968364#comment-15968364
]
Andrew Schwartzmeyer commented on ZOOKEEPER-2756:
-
The attached patch is what we'll be using for Mesos.
{quote}
Port build system to CMake.
This notably lacks Solaris and libtool support.
Almost everything else from Autotools has been ported,
including header/function/library checks, and all targets
(zookeeper, hashtable, cli, load_gen, and tests).
Both Linux and Windows are supported.
While `load_gen.c` looks at first glance as if it were ported to Windows,
it never actually was, so the erroneous `#include "win32port.h"` was
removed, and the target is not built on Windows.
There are existent warnings which this patch did not attempt to fix,
save a few easy ones.
Some changes to `winconfig.h` necessary to build with Visual Studio 2015
(and 2017) were included; these originally came from a patch embedded
inside the Mesos build process.
Final application of this patch should likely split these changes into a
few commits.
{quote}
> Add CMake build system for better cross-platform support
>
>
> Key: ZOOKEEPER-2756
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2756
> Project: ZooKeeper
> Issue Type: Improvement
> Components: build, c client
>Affects Versions: 3.5.2
> Environment: Windows and Linux
>Reporter: Andrew Schwartzmeyer
> Labels: build, windows
> Attachments: ZOOKEEPER-2756.patch
>
>
> The C bindings primary build system is Autotools. This obviously does not
> work for Windows, and so the original port to Windows simply added a Visual
> Studio solution to the project, splitting the build system. As new versions
> of Visual Studio have come along, new (probably auto-converted) solutions
> have come along (see zookeeper.sln vs zookeeper-vs2013.sln). When Mesos
> started being ported to Windows, a Visual Studio 2015 solution was needed,
> and the previous developer created yet another solution, and setup Mesos'
> build to patch ZooKeeper and add the 2015 solution. Now Visual Studio 2017
> was released, and in the process of moving Mesos ahead, I realized that I
> would either have to make *yet another* converted solution for ZooKeeper. So
> instead I tackled the root problem, and ported the Autotools build to CMake,
> which is a meta-build system which generates files for the in-use platform
> (whether it be Linux or Solaris or MacOS or Windows).
> NOTE: I already have this patch, and will submit it. It has a couple TODOs,
> and some other things in it that were necessary for Mesos that may need to be
> pulled into separate patches.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ZOOKEEPER-2756) Add CMake build system for better cross-platform support
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Schwartzmeyer updated ZOOKEEPER-2756: Attachment: ZOOKEEPER-2756.patch > Add CMake build system for better cross-platform support > > > Key: ZOOKEEPER-2756 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2756 > Project: ZooKeeper > Issue Type: Improvement > Components: build, c client >Affects Versions: 3.5.2 > Environment: Windows and Linux >Reporter: Andrew Schwartzmeyer > Labels: build, windows > Attachments: ZOOKEEPER-2756.patch > > > The C bindings primary build system is Autotools. This obviously does not > work for Windows, and so the original port to Windows simply added a Visual > Studio solution to the project, splitting the build system. As new versions > of Visual Studio have come along, new (probably auto-converted) solutions > have come along (see zookeeper.sln vs zookeeper-vs2013.sln). When Mesos > started being ported to Windows, a Visual Studio 2015 solution was needed, > and the previous developer created yet another solution, and setup Mesos' > build to patch ZooKeeper and add the 2015 solution. Now Visual Studio 2017 > was released, and in the process of moving Mesos ahead, I realized that I > would either have to make *yet another* converted solution for ZooKeeper. So > instead I tackled the root problem, and ported the Autotools build to CMake, > which is a meta-build system which generates files for the in-use platform > (whether it be Linux or Solaris or MacOS or Windows). > NOTE: I already have this patch, and will submit it. It has a couple TODOs, > and some other things in it that were necessary for Mesos that may need to be > pulled into separate patches. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (ZOOKEEPER-2756) Add CMake build system for better cross-platform support
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15968303#comment-15968303 ] Andrew Schwartzmeyer edited comment on ZOOKEEPER-2756 at 4/13/17 11:05 PM: --- Current work-in-progress patch is located at: https://github.com/andschwa/zookeeper/tree/cmake-3.5.2 This was specifically cherry-picked from on top of master to the latest release we're pulling into ZooKeeper. Open question: do we delete the deprecated Visual Studio solutions in the same patch? They're unmaintainable and should be removed. For discussion: eventual deprecation of Autotools in favor of CMake (which is what we're slowly working toward in Mesos). was (Author: andschwa): Current work-in-progress patch is located at: https://github.com/andschwa/zookeeper/tree/cmake-3.5.2 This was specifically cherry-picked from on top of master to the latest release we're pulling into ZooKeeper. I'll attach an actual patch file that can be applied to master, and list the remaining TODO items. Open question: do we delete the deprecated Visual Studio solutions in the same patch? They're unmaintainable and should be removed. For discussion: eventual deprecation of Autotools in favor of CMake (which is what we're slowly working toward in Mesos). > Add CMake build system for better cross-platform support > > > Key: ZOOKEEPER-2756 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2756 > Project: ZooKeeper > Issue Type: Improvement > Components: build, c client >Affects Versions: 3.5.2 > Environment: Windows and Linux >Reporter: Andrew Schwartzmeyer > Labels: build, windows > > The C bindings primary build system is Autotools. This obviously does not > work for Windows, and so the original port to Windows simply added a Visual > Studio solution to the project, splitting the build system. As new versions > of Visual Studio have come along, new (probably auto-converted) solutions > have come along (see zookeeper.sln vs zookeeper-vs2013.sln). When Mesos > started being ported to Windows, a Visual Studio 2015 solution was needed, > and the previous developer created yet another solution, and setup Mesos' > build to patch ZooKeeper and add the 2015 solution. Now Visual Studio 2017 > was released, and in the process of moving Mesos ahead, I realized that I > would either have to make *yet another* converted solution for ZooKeeper. So > instead I tackled the root problem, and ported the Autotools build to CMake, > which is a meta-build system which generates files for the in-use platform > (whether it be Linux or Solaris or MacOS or Windows). > NOTE: I already have this patch, and will submit it. It has a couple TODOs, > and some other things in it that were necessary for Mesos that may need to be > pulled into separate patches. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ZOOKEEPER-2756) Add CMake build system for better cross-platform support
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15968303#comment-15968303 ] Andrew Schwartzmeyer commented on ZOOKEEPER-2756: - Current work-in-progress patch is located at: https://github.com/andschwa/zookeeper/tree/cmake-3.5.2 This was specifically cherry-picked from on top of master to the latest release we're pulling into ZooKeeper. I'll attach an actual patch file that can be applied to master, and list the remaining TODO items. Open question: do we delete the deprecated Visual Studio solutions in the same patch? They're unmaintainable and should be removed. For discussion: eventual deprecation of Autotools in favor of CMake (which is what we're slowly working toward in Mesos). > Add CMake build system for better cross-platform support > > > Key: ZOOKEEPER-2756 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2756 > Project: ZooKeeper > Issue Type: Improvement > Components: build, c client >Affects Versions: 3.5.2 > Environment: Windows and Linux >Reporter: Andrew Schwartzmeyer > Labels: build, windows > > The C bindings primary build system is Autotools. This obviously does not > work for Windows, and so the original port to Windows simply added a Visual > Studio solution to the project, splitting the build system. As new versions > of Visual Studio have come along, new (probably auto-converted) solutions > have come along (see zookeeper.sln vs zookeeper-vs2013.sln). When Mesos > started being ported to Windows, a Visual Studio 2015 solution was needed, > and the previous developer created yet another solution, and setup Mesos' > build to patch ZooKeeper and add the 2015 solution. Now Visual Studio 2017 > was released, and in the process of moving Mesos ahead, I realized that I > would either have to make *yet another* converted solution for ZooKeeper. So > instead I tackled the root problem, and ported the Autotools build to CMake, > which is a meta-build system which generates files for the in-use platform > (whether it be Linux or Solaris or MacOS or Windows). > NOTE: I already have this patch, and will submit it. It has a couple TODOs, > and some other things in it that were necessary for Mesos that may need to be > pulled into separate patches. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ZOOKEEPER-2756) Add CMake build system for better cross-platform support
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15968280#comment-15968280 ] Andrew Schwartzmeyer commented on ZOOKEEPER-2756: - Can someone with permissions assign this to me? > Add CMake build system for better cross-platform support > > > Key: ZOOKEEPER-2756 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2756 > Project: ZooKeeper > Issue Type: Improvement > Components: build, c client >Affects Versions: 3.5.2 > Environment: Windows and Linux >Reporter: Andrew Schwartzmeyer > Labels: build, windows > > The C bindings primary build system is Autotools. This obviously does not > work for Windows, and so the original port to Windows simply added a Visual > Studio solution to the project, splitting the build system. As new versions > of Visual Studio have come along, new (probably auto-converted) solutions > have come along (see zookeeper.sln vs zookeeper-vs2013.sln). When Mesos > started being ported to Windows, a Visual Studio 2015 solution was needed, > and the previous developer created yet another solution, and setup Mesos' > build to patch ZooKeeper and add the 2015 solution. Now Visual Studio 2017 > was released, and in the process of moving Mesos ahead, I realized that I > would either have to make *yet another* converted solution for ZooKeeper. So > instead I tackled the root problem, and ported the Autotools build to CMake, > which is a meta-build system which generates files for the in-use platform > (whether it be Linux or Solaris or MacOS or Windows). > NOTE: I already have this patch, and will submit it. It has a couple TODOs, > and some other things in it that were necessary for Mesos that may need to be > pulled into separate patches. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ZOOKEEPER-2756) Add CMake build system for better cross-platform support
Andrew Schwartzmeyer created ZOOKEEPER-2756: --- Summary: Add CMake build system for better cross-platform support Key: ZOOKEEPER-2756 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2756 Project: ZooKeeper Issue Type: Improvement Components: build, c client Affects Versions: 3.5.2 Environment: Windows and Linux Reporter: Andrew Schwartzmeyer The C bindings primary build system is Autotools. This obviously does not work for Windows, and so the original port to Windows simply added a Visual Studio solution to the project, splitting the build system. As new versions of Visual Studio have come along, new (probably auto-converted) solutions have come along (see zookeeper.sln vs zookeeper-vs2013.sln). When Mesos started being ported to Windows, a Visual Studio 2015 solution was needed, and the previous developer created yet another solution, and setup Mesos' build to patch ZooKeeper and add the 2015 solution. Now Visual Studio 2017 was released, and in the process of moving Mesos ahead, I realized that I would either have to make *yet another* converted solution for ZooKeeper. So instead I tackled the root problem, and ported the Autotools build to CMake, which is a meta-build system which generates files for the in-use platform (whether it be Linux or Solaris or MacOS or Windows). NOTE: I already have this patch, and will submit it. It has a couple TODOs, and some other things in it that were necessary for Mesos that may need to be pulled into separate patches. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
