Discussion:
Plan for MSVC
(too old to reply)
Kenton Varda
2014-10-25 21:33:17 UTC
Permalink
Hi all,

I would like for version 0.5.0 to include basic MSVC support.

Bryan, since you've already investigated a lot of this, tell me if the
following makes sense.

I think that it's going to be tough to properly support the reflection
(schema and dynamic) APIs without full constexpr and expression SFINAE
support -- two things that MSVC is still missing. This is particularly true
after my recent changes to support generics, which required doing some more
expression SFINAE tricks.

However, I think it would be acceptable to simply disable reflection in
MSVC for now. Most people do not actually need it. Almost all of the
template tricks in the codebase are reflection-related -- even "kind<T>()".

Protobufs has long supported something called "lite mode" which drops
support for everything reflection-related. It turns out to be quite usable
in practice. Cap'n Proto doesn't have a lot of the problems that made lite
mode necessary for Protobufs, but we could do something very similar for
MSVC support.

Specific proposal: When macro CAPNP_LITE is defined to 1, all
reflection-related stuff will be skipped, and reflection-specific headers
will error out if included. On MSVC, we'll enable lite mode by default
(until the compiler catches up), but people could also define it on other
compilers to get a leaner library.

Note that if we don't support reflection, this implies we don't support
stringification (printing human-readable representations of messages),
because it relies on reflection. This kind of sucks, but it's a problem
Protobuf-lite has as well, and people get by. We could possibly solve it by
code-generating stringification methods instead, though that of course
means code bloat.

Thoughts?

If this seems good, then I'm going to go ahead and start inserting
CAPNP_LITE ifdefs.

We will need MinGW support in order to build the compiler binary (since
that definitely requires reflection). Joshua, you already did some work in
this direction. Care to continue that?

Bryan, once the CAPNP_LITE stuff is in, are you up for doing another pass
of getting it to work in MSVC and send me a pull request? BTW, note that we
actually have cmake support now, so let's make sure it works for the MSVC
build.

-Kenton
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Kenton Varda
2014-10-26 03:49:10 UTC
Permalink
I went ahead and implemented "lite mode", which is enabled by #defining
CAPNP_LITE=1.

https://github.com/kentonv/capnproto/commit/c772a70096b31061051b39e180ea807f82f6e024

Lite mode excludes the modules schema, schema-loader, dynamic, and
stringify from the library. It is also intended to avoid complex constexprs
or expression SFINAE, though more work is probably needed to root those
out. I have at least eliminated kind<T>().

I've set up the automake scripts to build in lite mode if you pass
--disable-reflection to configure. You will also need to use
--with-external-capnp (which implies you must build capnp normally before
trying to build in lite mode). I don't recommend anyone actually use this
for any reason other than testing that lite mode still works. Lite shaves
off more than half of the runtime library, which is neat, but irrelevant if
you are installing shared libraries anyway.

If someone with cmake experience wants to update the cmake files with a
similar option, that'd be great. :)

-Kenton
Post by Kenton Varda
Hi all,
I would like for version 0.5.0 to include basic MSVC support.
Bryan, since you've already investigated a lot of this, tell me if the
following makes sense.
I think that it's going to be tough to properly support the reflection
(schema and dynamic) APIs without full constexpr and expression SFINAE
support -- two things that MSVC is still missing. This is particularly true
after my recent changes to support generics, which required doing some more
expression SFINAE tricks.
However, I think it would be acceptable to simply disable reflection in
MSVC for now. Most people do not actually need it. Almost all of the
template tricks in the codebase are reflection-related -- even "kind<T>()".
Protobufs has long supported something called "lite mode" which drops
support for everything reflection-related. It turns out to be quite usable
in practice. Cap'n Proto doesn't have a lot of the problems that made lite
mode necessary for Protobufs, but we could do something very similar for
MSVC support.
Specific proposal: When macro CAPNP_LITE is defined to 1, all
reflection-related stuff will be skipped, and reflection-specific headers
will error out if included. On MSVC, we'll enable lite mode by default
(until the compiler catches up), but people could also define it on other
compilers to get a leaner library.
Note that if we don't support reflection, this implies we don't support
stringification (printing human-readable representations of messages),
because it relies on reflection. This kind of sucks, but it's a problem
Protobuf-lite has as well, and people get by. We could possibly solve it by
code-generating stringification methods instead, though that of course
means code bloat.
Thoughts?
If this seems good, then I'm going to go ahead and start inserting
CAPNP_LITE ifdefs.
We will need MinGW support in order to build the compiler binary (since
that definitely requires reflection). Joshua, you already did some work in
this direction. Care to continue that?
Bryan, once the CAPNP_LITE stuff is in, are you up for doing another pass
of getting it to work in MSVC and send me a pull request? BTW, note that we
actually have cmake support now, so let's make sure it works for the MSVC
build.
-Kenton
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Phil
2014-10-26 12:58:40 UTC
Permalink
Post by Kenton Varda
If someone with cmake experience wants to update the cmake files with a
similar option, that'd be great. :)
I'll be able to look at this over the next few days; I have a few more
cmake improvements to roll into it as well.

Philip
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Bryan Boreham
2014-11-06 17:57:53 UTC
Permalink
Hi Kenton, sorry for long pause.

I have installed the latest MSVC CTP, and it is a bit tighter on some
things than the one I was using before. I fixed up a few things, so the
code at https://github.com/bboreham/capnproto in branch bryan-vs14 compiles
the 'kj' directory; I haven't finished looking at 'capnproto'.

From what I see, the LITE mode is only in 'capnproto', so at least some
changes in 'kj' are needed to build with MSVC. I haven't had time to
analyse what the sweet-spot between the scale of changes I made and the
minimum possible in LITE mode.

I haven't done a pull request yet as it's still unfinished. Ideally I
would split the changes into a few parts, e.g. keep the MSVC 'solution' and
'project' files separate.

I think it's worth you taking a look over the changes - start in
kj/common.h, which will give you a feel, and then say whether you really
want this in 0.5.

Regards,

Bryan
Post by Kenton Varda
Hi all,
I would like for version 0.5.0 to include basic MSVC support.
Bryan, since you've already investigated a lot of this, tell me if the
following makes sense.
I think that it's going to be tough to properly support the reflection
(schema and dynamic) APIs without full constexpr and expression SFINAE
support -- two things that MSVC is still missing. This is particularly true
after my recent changes to support generics, which required doing some more
expression SFINAE tricks.
However, I think it would be acceptable to simply disable reflection in
MSVC for now. Most people do not actually need it. Almost all of the
template tricks in the codebase are reflection-related -- even "kind<T>()".
Protobufs has long supported something called "lite mode" which drops
support for everything reflection-related. It turns out to be quite usable
in practice. Cap'n Proto doesn't have a lot of the problems that made lite
mode necessary for Protobufs, but we could do something very similar for
MSVC support.
Specific proposal: When macro CAPNP_LITE is defined to 1, all
reflection-related stuff will be skipped, and reflection-specific headers
will error out if included. On MSVC, we'll enable lite mode by default
(until the compiler catches up), but people could also define it on other
compilers to get a leaner library.
Note that if we don't support reflection, this implies we don't support
stringification (printing human-readable representations of messages),
because it relies on reflection. This kind of sucks, but it's a problem
Protobuf-lite has as well, and people get by. We could possibly solve it by
code-generating stringification methods instead, though that of course
means code bloat.
Thoughts?
If this seems good, then I'm going to go ahead and start inserting
CAPNP_LITE ifdefs.
We will need MinGW support in order to build the compiler binary (since
that definitely requires reflection). Joshua, you already did some work in
this direction. Care to continue that?
Bryan, once the CAPNP_LITE stuff is in, are you up for doing another pass
of getting it to work in MSVC and send me a pull request? BTW, note that we
actually have cmake support now, so let's make sure it works for the MSVC
build.
-Kenton
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Klaim - Joël Lamotte
2014-11-07 21:11:04 UTC
Permalink
Hi guys,

As said before I'm using Protobuf with MSVC and I do use the lite mode
because I don't need any reflection feature.
I really need messages, maybe with some state but not actual reflection.
So having a lite mode in Capt'n'Proto when I switch to it would be useful.

About MSVC, my understanding is that MSVC14 CTP4 (the last one) does
implement constexpr but not for member functions,
see
http://blogs.msdn.com/b/vcblog/archive/2014/08/21/c-11-14-features-in-visual-studio-14-ctp3.aspx
So maybe it's still doable as Bryan seems to show.

I just say to point that Lite+VC14(+CMake) would be enough for me to switch
to Captnproto, so I would be happy to help with
testing in a real product.
Post by Bryan Boreham
Hi Kenton, sorry for long pause.
I have installed the latest MSVC CTP, and it is a bit tighter on some
things than the one I was using before. I fixed up a few things, so the
code at https://github.com/bboreham/capnproto in branch bryan-vs14
compiles the 'kj' directory; I haven't finished looking at 'capnproto'.
From what I see, the LITE mode is only in 'capnproto', so at least some
changes in 'kj' are needed to build with MSVC. I haven't had time to
analyse what the sweet-spot between the scale of changes I made and the
minimum possible in LITE mode.
I haven't done a pull request yet as it's still unfinished. Ideally I
would split the changes into a few parts, e.g. keep the MSVC 'solution' and
'project' files separate.
I think it's worth you taking a look over the changes - start in
kj/common.h, which will give you a feel, and then say whether you really
want this in 0.5.
Regards,
Bryan
Post by Kenton Varda
Hi all,
I would like for version 0.5.0 to include basic MSVC support.
Bryan, since you've already investigated a lot of this, tell me if the
following makes sense.
I think that it's going to be tough to properly support the reflection
(schema and dynamic) APIs without full constexpr and expression SFINAE
support -- two things that MSVC is still missing. This is particularly true
after my recent changes to support generics, which required doing some more
expression SFINAE tricks.
However, I think it would be acceptable to simply disable reflection in
MSVC for now. Most people do not actually need it. Almost all of the
template tricks in the codebase are reflection-related -- even "kind<T>()".
Protobufs has long supported something called "lite mode" which drops
support for everything reflection-related. It turns out to be quite usable
in practice. Cap'n Proto doesn't have a lot of the problems that made lite
mode necessary for Protobufs, but we could do something very similar for
MSVC support.
Specific proposal: When macro CAPNP_LITE is defined to 1, all
reflection-related stuff will be skipped, and reflection-specific headers
will error out if included. On MSVC, we'll enable lite mode by default
(until the compiler catches up), but people could also define it on other
compilers to get a leaner library.
Note that if we don't support reflection, this implies we don't support
stringification (printing human-readable representations of messages),
because it relies on reflection. This kind of sucks, but it's a problem
Protobuf-lite has as well, and people get by. We could possibly solve it by
code-generating stringification methods instead, though that of course
means code bloat.
Thoughts?
If this seems good, then I'm going to go ahead and start inserting
CAPNP_LITE ifdefs.
We will need MinGW support in order to build the compiler binary (since
that definitely requires reflection). Joshua, you already did some work in
this direction. Care to continue that?
Bryan, once the CAPNP_LITE stuff is in, are you up for doing another pass
of getting it to work in MSVC and send me a pull request? BTW, note that we
actually have cmake support now, so let's make sure it works for the MSVC
build.
-Kenton
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Kenton Varda
2014-11-07 21:39:24 UTC
Permalink
Hi Bryan,

The changes look acceptable although some cleanup is obviously needed.

It occurs to me that most of the KJ library is actually not used by lite
mode Cap'n Proto and therefore can be skipped. Sorry, I should have gone
through this list earlier!

You can skip at least the following:
- kj/async*: Only used by RPC.
- kj/parse, kj/tuple, kj/oneof: Only used by schema parser, i.e. the
compiler, which we'll build with MinGW.
- kj/main: Only used by command-line tools, i.e. again the compiler.
- kj/refcount: Used by RPC and compiler.
- kj/mutex, kj/threadlocal, kj/arena: Used by SchemaLoader, compiler, and
RPC -- none of which is in lite mode.
- kj/string-tree: Not used in lite mode.

-Kenton
Post by Bryan Boreham
Hi Kenton, sorry for long pause.
I have installed the latest MSVC CTP, and it is a bit tighter on some
things than the one I was using before. I fixed up a few things, so the
code at https://github.com/bboreham/capnproto in branch bryan-vs14
compiles the 'kj' directory; I haven't finished looking at 'capnproto'.
From what I see, the LITE mode is only in 'capnproto', so at least some
changes in 'kj' are needed to build with MSVC. I haven't had time to
analyse what the sweet-spot between the scale of changes I made and the
minimum possible in LITE mode.
I haven't done a pull request yet as it's still unfinished. Ideally I
would split the changes into a few parts, e.g. keep the MSVC 'solution' and
'project' files separate.
I think it's worth you taking a look over the changes - start in
kj/common.h, which will give you a feel, and then say whether you really
want this in 0.5.
Regards,
Bryan
Post by Kenton Varda
Hi all,
I would like for version 0.5.0 to include basic MSVC support.
Bryan, since you've already investigated a lot of this, tell me if the
following makes sense.
I think that it's going to be tough to properly support the reflection
(schema and dynamic) APIs without full constexpr and expression SFINAE
support -- two things that MSVC is still missing. This is particularly true
after my recent changes to support generics, which required doing some more
expression SFINAE tricks.
However, I think it would be acceptable to simply disable reflection in
MSVC for now. Most people do not actually need it. Almost all of the
template tricks in the codebase are reflection-related -- even "kind<T>()".
Protobufs has long supported something called "lite mode" which drops
support for everything reflection-related. It turns out to be quite usable
in practice. Cap'n Proto doesn't have a lot of the problems that made lite
mode necessary for Protobufs, but we could do something very similar for
MSVC support.
Specific proposal: When macro CAPNP_LITE is defined to 1, all
reflection-related stuff will be skipped, and reflection-specific headers
will error out if included. On MSVC, we'll enable lite mode by default
(until the compiler catches up), but people could also define it on other
compilers to get a leaner library.
Note that if we don't support reflection, this implies we don't support
stringification (printing human-readable representations of messages),
because it relies on reflection. This kind of sucks, but it's a problem
Protobuf-lite has as well, and people get by. We could possibly solve it by
code-generating stringification methods instead, though that of course
means code bloat.
Thoughts?
If this seems good, then I'm going to go ahead and start inserting
CAPNP_LITE ifdefs.
We will need MinGW support in order to build the compiler binary (since
that definitely requires reflection). Joshua, you already did some work in
this direction. Care to continue that?
Bryan, once the CAPNP_LITE stuff is in, are you up for doing another pass
of getting it to work in MSVC and send me a pull request? BTW, note that we
actually have cmake support now, so let's make sure it works for the MSVC
build.
-Kenton
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Bryan Boreham
2014-11-16 20:04:57 UTC
Permalink
I got back to looking at this again, but it seems that a change in
capnp/common.h has stumped MSVC again:

capnproto\c++\src\capnp\common.h(112): error C2668: 'capnp::_::kindSfinae':
ambiguous call to overloaded function
capnproto\c++\src\capnp\common.h(110): note: could be 'uint64_t
capnp::_::kindSfinae<T>(...)'
capnproto\c++\src\capnp\common.h(109): note: or 'uint32_t
capnp::_::kindSfinae<T,schemas::EnumInfo<T>::IsEnum>(int)'
capnproto\c++\src\capnp\common.h(108): note: or 'uint16_t
capnp::_::kindSfinae<T,T::_capnpPrivate::IsInterface>(int)'
capnproto\c++\src\capnp\common.h(107): note: or 'uint8_t
capnp::_::kindSfinae<T,T::_capnpPrivate::IsStruct>(int)'
capnproto\c++\src\capnp\common.h(112): note: while trying to match the
argument list '(int)'

The error report seems to get triggered by this kind of usage:

template <typename T> struct ListElementType_<List<T>> { typedef T Type; };

Seems MSVC is being a bit eager trying to figure out what it all means
before anyone came up with a T yet.
I spent some time playing around trying different ways to code it, but
didn't really get anywhere.
Do you have any suggestions?

Regards,

Bryan
Post by Kenton Varda
Hi Bryan,
The changes look acceptable although some cleanup is obviously needed.
It occurs to me that most of the KJ library is actually not used by lite
mode Cap'n Proto and therefore can be skipped. Sorry, I should have gone
through this list earlier!
- kj/async*: Only used by RPC.
- kj/parse, kj/tuple, kj/oneof: Only used by schema parser, i.e. the
compiler, which we'll build with MinGW.
- kj/main: Only used by command-line tools, i.e. again the compiler.
- kj/refcount: Used by RPC and compiler.
- kj/mutex, kj/threadlocal, kj/arena: Used by SchemaLoader, compiler, and
RPC -- none of which is in lite mode.
- kj/string-tree: Not used in lite mode.
-Kenton
Post by Bryan Boreham
Hi Kenton, sorry for long pause.
I have installed the latest MSVC CTP, and it is a bit tighter on some
things than the one I was using before. I fixed up a few things, so the
code at https://github.com/bboreham/capnproto in branch bryan-vs14
compiles the 'kj' directory; I haven't finished looking at 'capnproto'.
From what I see, the LITE mode is only in 'capnproto', so at least some
changes in 'kj' are needed to build with MSVC. I haven't had time to
analyse what the sweet-spot between the scale of changes I made and the
minimum possible in LITE mode.
I haven't done a pull request yet as it's still unfinished. Ideally I
would split the changes into a few parts, e.g. keep the MSVC 'solution' and
'project' files separate.
I think it's worth you taking a look over the changes - start in
kj/common.h, which will give you a feel, and then say whether you really
want this in 0.5.
Regards,
Bryan
Post by Kenton Varda
Hi all,
I would like for version 0.5.0 to include basic MSVC support.
Bryan, since you've already investigated a lot of this, tell me if the
following makes sense.
I think that it's going to be tough to properly support the reflection
(schema and dynamic) APIs without full constexpr and expression SFINAE
support -- two things that MSVC is still missing. This is particularly true
after my recent changes to support generics, which required doing some more
expression SFINAE tricks.
However, I think it would be acceptable to simply disable reflection in
MSVC for now. Most people do not actually need it. Almost all of the
template tricks in the codebase are reflection-related -- even "kind<T>()".
Protobufs has long supported something called "lite mode" which drops
support for everything reflection-related. It turns out to be quite usable
in practice. Cap'n Proto doesn't have a lot of the problems that made lite
mode necessary for Protobufs, but we could do something very similar for
MSVC support.
Specific proposal: When macro CAPNP_LITE is defined to 1, all
reflection-related stuff will be skipped, and reflection-specific headers
will error out if included. On MSVC, we'll enable lite mode by default
(until the compiler catches up), but people could also define it on other
compilers to get a leaner library.
Note that if we don't support reflection, this implies we don't support
stringification (printing human-readable representations of messages),
because it relies on reflection. This kind of sucks, but it's a problem
Protobuf-lite has as well, and people get by. We could possibly solve it by
code-generating stringification methods instead, though that of course
means code bloat.
Thoughts?
If this seems good, then I'm going to go ahead and start inserting
CAPNP_LITE ifdefs.
We will need MinGW support in order to build the compiler binary (since
that definitely requires reflection). Joshua, you already did some work in
this direction. Care to continue that?
Bryan, once the CAPNP_LITE stuff is in, are you up for doing another
pass of getting it to work in MSVC and send me a pull request? BTW, note
that we actually have cmake support now, so let's make sure it works for
the MSVC build.
-Kenton
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Kenton Varda
2014-11-17 01:37:06 UTC
Permalink
Dang, I was trying to be careful to use only type-based SFINAE in the hopes
that it would make MSVC happy. Doesn't the standard library do this kind of
thing a lot, e.g. in type_traits?

I don't know off the top of my head what to do about this. I will probably
start playing with it myself soon. Was planning to install MSVS'15 Preview
this week or next to take a look.

-Kenton
Post by Bryan Boreham
I got back to looking at this again, but it seems that a change in
'capnp::_::kindSfinae': ambiguous call to overloaded function
capnproto\c++\src\capnp\common.h(110): note: could be 'uint64_t
capnp::_::kindSfinae<T>(...)'
capnproto\c++\src\capnp\common.h(109): note: or 'uint32_t
capnp::_::kindSfinae<T,schemas::EnumInfo<T>::IsEnum>(int)'
capnproto\c++\src\capnp\common.h(108): note: or 'uint16_t
capnp::_::kindSfinae<T,T::_capnpPrivate::IsInterface>(int)'
capnproto\c++\src\capnp\common.h(107): note: or 'uint8_t
capnp::_::kindSfinae<T,T::_capnpPrivate::IsStruct>(int)'
capnproto\c++\src\capnp\common.h(112): note: while trying to match the
argument list '(int)'
template <typename T> struct ListElementType_<List<T>> { typedef T Type; };
Seems MSVC is being a bit eager trying to figure out what it all means
before anyone came up with a T yet.
I spent some time playing around trying different ways to code it, but
didn't really get anywhere.
Do you have any suggestions?
Regards,
Bryan
Post by Kenton Varda
Hi Bryan,
The changes look acceptable although some cleanup is obviously needed.
It occurs to me that most of the KJ library is actually not used by lite
mode Cap'n Proto and therefore can be skipped. Sorry, I should have gone
through this list earlier!
- kj/async*: Only used by RPC.
- kj/parse, kj/tuple, kj/oneof: Only used by schema parser, i.e. the
compiler, which we'll build with MinGW.
- kj/main: Only used by command-line tools, i.e. again the compiler.
- kj/refcount: Used by RPC and compiler.
- kj/mutex, kj/threadlocal, kj/arena: Used by SchemaLoader, compiler, and
RPC -- none of which is in lite mode.
- kj/string-tree: Not used in lite mode.
-Kenton
Post by Bryan Boreham
Hi Kenton, sorry for long pause.
I have installed the latest MSVC CTP, and it is a bit tighter on some
things than the one I was using before. I fixed up a few things, so the
code at https://github.com/bboreham/capnproto in branch bryan-vs14
compiles the 'kj' directory; I haven't finished looking at 'capnproto'.
From what I see, the LITE mode is only in 'capnproto', so at least some
changes in 'kj' are needed to build with MSVC. I haven't had time to
analyse what the sweet-spot between the scale of changes I made and the
minimum possible in LITE mode.
I haven't done a pull request yet as it's still unfinished. Ideally I
would split the changes into a few parts, e.g. keep the MSVC 'solution' and
'project' files separate.
I think it's worth you taking a look over the changes - start in
kj/common.h, which will give you a feel, and then say whether you really
want this in 0.5.
Regards,
Bryan
Post by Kenton Varda
Hi all,
I would like for version 0.5.0 to include basic MSVC support.
Bryan, since you've already investigated a lot of this, tell me if the
following makes sense.
I think that it's going to be tough to properly support the reflection
(schema and dynamic) APIs without full constexpr and expression SFINAE
support -- two things that MSVC is still missing. This is particularly true
after my recent changes to support generics, which required doing some more
expression SFINAE tricks.
However, I think it would be acceptable to simply disable reflection in
MSVC for now. Most people do not actually need it. Almost all of the
template tricks in the codebase are reflection-related -- even "kind<T>()".
Protobufs has long supported something called "lite mode" which drops
support for everything reflection-related. It turns out to be quite usable
in practice. Cap'n Proto doesn't have a lot of the problems that made lite
mode necessary for Protobufs, but we could do something very similar for
MSVC support.
Specific proposal: When macro CAPNP_LITE is defined to 1, all
reflection-related stuff will be skipped, and reflection-specific headers
will error out if included. On MSVC, we'll enable lite mode by default
(until the compiler catches up), but people could also define it on other
compilers to get a leaner library.
Note that if we don't support reflection, this implies we don't support
stringification (printing human-readable representations of messages),
because it relies on reflection. This kind of sucks, but it's a problem
Protobuf-lite has as well, and people get by. We could possibly solve it by
code-generating stringification methods instead, though that of course
means code bloat.
Thoughts?
If this seems good, then I'm going to go ahead and start inserting
CAPNP_LITE ifdefs.
We will need MinGW support in order to build the compiler binary (since
that definitely requires reflection). Joshua, you already did some work in
this direction. Care to continue that?
Bryan, once the CAPNP_LITE stuff is in, are you up for doing another
pass of getting it to work in MSVC and send me a pull request? BTW, note
that we actually have cmake support now, so let's make sure it works for
the MSVC build.
-Kenton
--
You received this message because you are subscribed to the Google
Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
David Anes
2014-11-18 10:20:51 UTC
Permalink
Just to shed some light on this:

http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17-features-in-vs-2015-preview.aspx

Hope this helps.
Post by Kenton Varda
Dang, I was trying to be careful to use only type-based SFINAE in the
hopes that it would make MSVC happy. Doesn't the standard library do this
kind of thing a lot, e.g. in type_traits?
I don't know off the top of my head what to do about this. I will probably
start playing with it myself soon. Was planning to install MSVS'15 Preview
this week or next to take a look.
-Kenton
Post by Bryan Boreham
I got back to looking at this again, but it seems that a change in
'capnp::_::kindSfinae': ambiguous call to overloaded function
capnproto\c++\src\capnp\common.h(110): note: could be 'uint64_t
capnp::_::kindSfinae<T>(...)'
capnproto\c++\src\capnp\common.h(109): note: or 'uint32_t
capnp::_::kindSfinae<T,schemas::EnumInfo<T>::IsEnum>(int)'
capnproto\c++\src\capnp\common.h(108): note: or 'uint16_t
capnp::_::kindSfinae<T,T::_capnpPrivate::IsInterface>(int)'
capnproto\c++\src\capnp\common.h(107): note: or 'uint8_t
capnp::_::kindSfinae<T,T::_capnpPrivate::IsStruct>(int)'
capnproto\c++\src\capnp\common.h(112): note: while trying to match the
argument list '(int)'
template <typename T> struct ListElementType_<List<T>> { typedef T Type; };
Seems MSVC is being a bit eager trying to figure out what it all means
before anyone came up with a T yet.
I spent some time playing around trying different ways to code it, but
didn't really get anywhere.
Do you have any suggestions?
Regards,
Bryan
Post by Kenton Varda
Hi Bryan,
The changes look acceptable although some cleanup is obviously needed.
It occurs to me that most of the KJ library is actually not used by lite
mode Cap'n Proto and therefore can be skipped. Sorry, I should have gone
through this list earlier!
- kj/async*: Only used by RPC.
- kj/parse, kj/tuple, kj/oneof: Only used by schema parser, i.e. the
compiler, which we'll build with MinGW.
- kj/main: Only used by command-line tools, i.e. again the compiler.
- kj/refcount: Used by RPC and compiler.
- kj/mutex, kj/threadlocal, kj/arena: Used by SchemaLoader, compiler,
and RPC -- none of which is in lite mode.
- kj/string-tree: Not used in lite mode.
-Kenton
Post by Bryan Boreham
Hi Kenton, sorry for long pause.
I have installed the latest MSVC CTP, and it is a bit tighter on some
things than the one I was using before. I fixed up a few things, so the
code at https://github.com/bboreham/capnproto in branch bryan-vs14
compiles the 'kj' directory; I haven't finished looking at 'capnproto'.
From what I see, the LITE mode is only in 'capnproto', so at least some
changes in 'kj' are needed to build with MSVC. I haven't had time to
analyse what the sweet-spot between the scale of changes I made and the
minimum possible in LITE mode.
I haven't done a pull request yet as it's still unfinished. Ideally I
would split the changes into a few parts, e.g. keep the MSVC 'solution' and
'project' files separate.
I think it's worth you taking a look over the changes - start in
kj/common.h, which will give you a feel, and then say whether you really
want this in 0.5.
Regards,
Bryan
Post by Kenton Varda
Hi all,
I would like for version 0.5.0 to include basic MSVC support.
Bryan, since you've already investigated a lot of this, tell me if the
following makes sense.
I think that it's going to be tough to properly support the reflection
(schema and dynamic) APIs without full constexpr and expression SFINAE
support -- two things that MSVC is still missing. This is particularly true
after my recent changes to support generics, which required doing some more
expression SFINAE tricks.
However, I think it would be acceptable to simply disable reflection
in MSVC for now. Most people do not actually need it. Almost all of the
template tricks in the codebase are reflection-related -- even "kind<T>()".
Protobufs has long supported something called "lite mode" which drops
support for everything reflection-related. It turns out to be quite usable
in practice. Cap'n Proto doesn't have a lot of the problems that made lite
mode necessary for Protobufs, but we could do something very similar for
MSVC support.
Specific proposal: When macro CAPNP_LITE is defined to 1, all
reflection-related stuff will be skipped, and reflection-specific headers
will error out if included. On MSVC, we'll enable lite mode by default
(until the compiler catches up), but people could also define it on other
compilers to get a leaner library.
Note that if we don't support reflection, this implies we don't
support stringification (printing human-readable representations of
messages), because it relies on reflection. This kind of sucks, but it's a
problem Protobuf-lite has as well, and people get by. We could possibly
solve it by code-generating stringification methods instead, though that of
course means code bloat.
Thoughts?
If this seems good, then I'm going to go ahead and start inserting
CAPNP_LITE ifdefs.
We will need MinGW support in order to build the compiler binary
(since that definitely requires reflection). Joshua, you already did some
work in this direction. Care to continue that?
Bryan, once the CAPNP_LITE stuff is in, are you up for doing another
pass of getting it to work in MSVC and send me a pull request? BTW, note
that we actually have cmake support now, so let's make sure it works for
the MSVC build.
-Kenton
--
You received this message because you are subscribed to the Google
Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/capnproto.
--
David "kraptor" Anes Alcolea
* @kraptor <http://twitter.com/kraptor> @simlaps
<http://twitter.com/simlaps>
* linkedin.com/in/davidanes
* kraptor.com | simlaps.com | 900grados.es
<http://simlaps.com>
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Kenton Varda
2014-11-18 20:10:38 UTC
Permalink
Looks like not much has changed since the last CTP. Expression SFINAE and
incomplete constexpr are going to continue to be a problem. :/

In good news, I got the capnp compiler building on MinGW yesterday, and am
now working on eliminating the dependency on winpthreads. Cross-compiling
to MinGW on Linux and then testing on Wine was surprisingly easy. I wonder
if I can get cl.exe to run in Wine... would make it much easier to
integrate Windows testing into my workflow.

-Kenton
Post by David Anes
http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17-features-in-vs-2015-preview.aspx
Hope this helps.
Post by Kenton Varda
Dang, I was trying to be careful to use only type-based SFINAE in the
hopes that it would make MSVC happy. Doesn't the standard library do this
kind of thing a lot, e.g. in type_traits?
I don't know off the top of my head what to do about this. I will
probably start playing with it myself soon. Was planning to install MSVS'15
Preview this week or next to take a look.
-Kenton
Post by Bryan Boreham
I got back to looking at this again, but it seems that a change in
'capnp::_::kindSfinae': ambiguous call to overloaded function
capnproto\c++\src\capnp\common.h(110): note: could be 'uint64_t
capnp::_::kindSfinae<T>(...)'
capnproto\c++\src\capnp\common.h(109): note: or 'uint32_t
capnp::_::kindSfinae<T,schemas::EnumInfo<T>::IsEnum>(int)'
capnproto\c++\src\capnp\common.h(108): note: or 'uint16_t
capnp::_::kindSfinae<T,T::_capnpPrivate::IsInterface>(int)'
capnproto\c++\src\capnp\common.h(107): note: or 'uint8_t
capnp::_::kindSfinae<T,T::_capnpPrivate::IsStruct>(int)'
capnproto\c++\src\capnp\common.h(112): note: while trying to match the
argument list '(int)'
template <typename T> struct ListElementType_<List<T>> { typedef T Type; };
Seems MSVC is being a bit eager trying to figure out what it all means
before anyone came up with a T yet.
I spent some time playing around trying different ways to code it, but
didn't really get anywhere.
Do you have any suggestions?
Regards,
Bryan
Post by Kenton Varda
Hi Bryan,
The changes look acceptable although some cleanup is obviously needed.
It occurs to me that most of the KJ library is actually not used by
lite mode Cap'n Proto and therefore can be skipped. Sorry, I should have
gone through this list earlier!
- kj/async*: Only used by RPC.
- kj/parse, kj/tuple, kj/oneof: Only used by schema parser, i.e. the
compiler, which we'll build with MinGW.
- kj/main: Only used by command-line tools, i.e. again the compiler.
- kj/refcount: Used by RPC and compiler.
- kj/mutex, kj/threadlocal, kj/arena: Used by SchemaLoader, compiler,
and RPC -- none of which is in lite mode.
- kj/string-tree: Not used in lite mode.
-Kenton
Post by Bryan Boreham
Hi Kenton, sorry for long pause.
I have installed the latest MSVC CTP, and it is a bit tighter on some
things than the one I was using before. I fixed up a few things, so the
code at https://github.com/bboreham/capnproto in branch bryan-vs14
compiles the 'kj' directory; I haven't finished looking at 'capnproto'.
From what I see, the LITE mode is only in 'capnproto', so at least
some changes in 'kj' are needed to build with MSVC. I haven't had time to
analyse what the sweet-spot between the scale of changes I made and the
minimum possible in LITE mode.
I haven't done a pull request yet as it's still unfinished. Ideally I
would split the changes into a few parts, e.g. keep the MSVC 'solution' and
'project' files separate.
I think it's worth you taking a look over the changes - start in
kj/common.h, which will give you a feel, and then say whether you really
want this in 0.5.
Regards,
Bryan
Post by Kenton Varda
Hi all,
I would like for version 0.5.0 to include basic MSVC support.
Bryan, since you've already investigated a lot of this, tell me if
the following makes sense.
I think that it's going to be tough to properly support the
reflection (schema and dynamic) APIs without full constexpr and expression
SFINAE support -- two things that MSVC is still missing. This is
particularly true after my recent changes to support generics, which
required doing some more expression SFINAE tricks.
However, I think it would be acceptable to simply disable reflection
in MSVC for now. Most people do not actually need it. Almost all of the
template tricks in the codebase are reflection-related -- even "kind<T>()".
Protobufs has long supported something called "lite mode" which drops
support for everything reflection-related. It turns out to be quite usable
in practice. Cap'n Proto doesn't have a lot of the problems that made lite
mode necessary for Protobufs, but we could do something very similar for
MSVC support.
Specific proposal: When macro CAPNP_LITE is defined to 1, all
reflection-related stuff will be skipped, and reflection-specific headers
will error out if included. On MSVC, we'll enable lite mode by default
(until the compiler catches up), but people could also define it on other
compilers to get a leaner library.
Note that if we don't support reflection, this implies we don't
support stringification (printing human-readable representations of
messages), because it relies on reflection. This kind of sucks, but it's a
problem Protobuf-lite has as well, and people get by. We could possibly
solve it by code-generating stringification methods instead, though that of
course means code bloat.
Thoughts?
If this seems good, then I'm going to go ahead and start inserting
CAPNP_LITE ifdefs.
We will need MinGW support in order to build the compiler binary
(since that definitely requires reflection). Joshua, you already did some
work in this direction. Care to continue that?
Bryan, once the CAPNP_LITE stuff is in, are you up for doing another
pass of getting it to work in MSVC and send me a pull request? BTW, note
that we actually have cmake support now, so let's make sure it works for
the MSVC build.
-Kenton
--
You received this message because you are subscribed to the Google
Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google
Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/capnproto.
--
David "kraptor" Anes Alcolea
<http://twitter.com/simlaps>
* linkedin.com/in/davidanes
* kraptor.com | simlaps.com | 900grados.es
<http://simlaps.com>
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Kenton Varda
2014-11-23 04:16:51 UTC
Permalink
Hi all,

1) MinGW can now compile all lite-mode tests as well as a working capnp
binary that depends only on kernel32 and msvcrt. Configure like so:
./configure --disable-shared CXXFLAGS='-static-libgcc -static-libstdc++'

Or if cross-compiling from Linux, do:
./configure --host=x86_64-w64-mingw32 --with-external-capnp
--disable-shared CXXFLAGS='-static-libgcc -static-libstdc++'

2) I just pushed a basic MSVC project file that covers the parts of KJ
needed by capnp-lite (including respective tests).

- Only KJ covered so far. Going to start on capnp next.
- I only bothered to port the parts of KJ needed by capnp-lite, which turns
out to be a tiny subset. Specifically, the required modules are: array,
common, debug, exception, io, memory, string, miniposix (new).
- You'll need to run setup-autotools.sh in cygwin -- or download gtest
manually -- before the project file will work.
- Although I didn't directly pull Bryan's code, I had it open in a window
as I did this, and took a bunch of solutions from it. Thanks, Bryan! I've
added you to the CONTRIBUTORS list.

One thing I haven't figured out is cmake on Windows. I tried using cmake to
build MSVC projects and it simply didn't work. It looks like it was trying
to build project files for MSVC 2013 and those failed with 2015, but cmake
didn't give MSVC an opportunity to run the project updater flow before
failing out.

Since I don't know cmake, I feel like I'm flailing in the dark here. Could
someone who knows cmake look into how to make it work with VS2015 Preview
and write up some instructions? We should also modify the cmake files to
only compile above-mentioned subset of KJ in lite mode. (We should probably
do the same with Makefile.am, but that's not as important.)

Thanks!

-Kenton
Post by Kenton Varda
Looks like not much has changed since the last CTP. Expression SFINAE and
incomplete constexpr are going to continue to be a problem. :/
In good news, I got the capnp compiler building on MinGW yesterday, and am
now working on eliminating the dependency on winpthreads. Cross-compiling
to MinGW on Linux and then testing on Wine was surprisingly easy. I wonder
if I can get cl.exe to run in Wine... would make it much easier to
integrate Windows testing into my workflow.
-Kenton
Post by David Anes
http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17-features-in-vs-2015-preview.aspx
Hope this helps.
Post by Kenton Varda
Dang, I was trying to be careful to use only type-based SFINAE in the
hopes that it would make MSVC happy. Doesn't the standard library do this
kind of thing a lot, e.g. in type_traits?
I don't know off the top of my head what to do about this. I will
probably start playing with it myself soon. Was planning to install MSVS'15
Preview this week or next to take a look.
-Kenton
Post by Bryan Boreham
I got back to looking at this again, but it seems that a change in
'capnp::_::kindSfinae': ambiguous call to overloaded function
capnproto\c++\src\capnp\common.h(110): note: could be 'uint64_t
capnp::_::kindSfinae<T>(...)'
capnproto\c++\src\capnp\common.h(109): note: or 'uint32_t
capnp::_::kindSfinae<T,schemas::EnumInfo<T>::IsEnum>(int)'
capnproto\c++\src\capnp\common.h(108): note: or 'uint16_t
capnp::_::kindSfinae<T,T::_capnpPrivate::IsInterface>(int)'
capnproto\c++\src\capnp\common.h(107): note: or 'uint8_t
capnp::_::kindSfinae<T,T::_capnpPrivate::IsStruct>(int)'
capnproto\c++\src\capnp\common.h(112): note: while trying to match the
argument list '(int)'
template <typename T> struct ListElementType_<List<T>> { typedef T Type; };
Seems MSVC is being a bit eager trying to figure out what it all means
before anyone came up with a T yet.
I spent some time playing around trying different ways to code it, but
didn't really get anywhere.
Do you have any suggestions?
Regards,
Bryan
Post by Kenton Varda
Hi Bryan,
The changes look acceptable although some cleanup is obviously needed.
It occurs to me that most of the KJ library is actually not used by
lite mode Cap'n Proto and therefore can be skipped. Sorry, I should have
gone through this list earlier!
- kj/async*: Only used by RPC.
- kj/parse, kj/tuple, kj/oneof: Only used by schema parser, i.e. the
compiler, which we'll build with MinGW.
- kj/main: Only used by command-line tools, i.e. again the compiler.
- kj/refcount: Used by RPC and compiler.
- kj/mutex, kj/threadlocal, kj/arena: Used by SchemaLoader, compiler,
and RPC -- none of which is in lite mode.
- kj/string-tree: Not used in lite mode.
-Kenton
Post by Bryan Boreham
Hi Kenton, sorry for long pause.
I have installed the latest MSVC CTP, and it is a bit tighter on some
things than the one I was using before. I fixed up a few things, so the
code at https://github.com/bboreham/capnproto in branch bryan-vs14
compiles the 'kj' directory; I haven't finished looking at 'capnproto'.
From what I see, the LITE mode is only in 'capnproto', so at least
some changes in 'kj' are needed to build with MSVC. I haven't had time to
analyse what the sweet-spot between the scale of changes I made and the
minimum possible in LITE mode.
I haven't done a pull request yet as it's still unfinished. Ideally
I would split the changes into a few parts, e.g. keep the MSVC 'solution'
and 'project' files separate.
I think it's worth you taking a look over the changes - start in
kj/common.h, which will give you a feel, and then say whether you really
want this in 0.5.
Regards,
Bryan
Post by Kenton Varda
Hi all,
I would like for version 0.5.0 to include basic MSVC support.
Bryan, since you've already investigated a lot of this, tell me if
the following makes sense.
I think that it's going to be tough to properly support the
reflection (schema and dynamic) APIs without full constexpr and expression
SFINAE support -- two things that MSVC is still missing. This is
particularly true after my recent changes to support generics, which
required doing some more expression SFINAE tricks.
However, I think it would be acceptable to simply disable reflection
in MSVC for now. Most people do not actually need it. Almost all of the
template tricks in the codebase are reflection-related -- even "kind<T>()".
Protobufs has long supported something called "lite mode" which
drops support for everything reflection-related. It turns out to be quite
usable in practice. Cap'n Proto doesn't have a lot of the problems that
made lite mode necessary for Protobufs, but we could do something very
similar for MSVC support.
Specific proposal: When macro CAPNP_LITE is defined to 1, all
reflection-related stuff will be skipped, and reflection-specific headers
will error out if included. On MSVC, we'll enable lite mode by default
(until the compiler catches up), but people could also define it on other
compilers to get a leaner library.
Note that if we don't support reflection, this implies we don't
support stringification (printing human-readable representations of
messages), because it relies on reflection. This kind of sucks, but it's a
problem Protobuf-lite has as well, and people get by. We could possibly
solve it by code-generating stringification methods instead, though that of
course means code bloat.
Thoughts?
If this seems good, then I'm going to go ahead and start inserting
CAPNP_LITE ifdefs.
We will need MinGW support in order to build the compiler binary
(since that definitely requires reflection). Joshua, you already did some
work in this direction. Care to continue that?
Bryan, once the CAPNP_LITE stuff is in, are you up for doing another
pass of getting it to work in MSVC and send me a pull request? BTW, note
that we actually have cmake support now, so let's make sure it works for
the MSVC build.
-Kenton
--
You received this message because you are subscribed to the Google
Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it,
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google
Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google
Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/capnproto.
--
David "kraptor" Anes Alcolea
<http://twitter.com/simlaps>
* linkedin.com/in/davidanes
* kraptor.com | simlaps.com | 900grados.es
<http://simlaps.com>
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Kenton Varda
2014-11-24 09:16:03 UTC
Permalink
Hey Everyone!

It's official: Cap'n Proto Lite compiles under MSVC 2015 and all tests
pass! Thanks to Bryan for lots of help.

Right now, I've just created a single MSVC project file that just builds
the code and tests together into one executable. Obviously, that's not what
we want. We want a library.

As I said before, instead of maintaining vcproj files, I'd really like for
the cmake build to be able to auto-generate them. But, I don't know cmake!
I tried poking at it and it puked. Can someone with experience with cmake
and MSVC please make this work? Joshua?

Note that I think the cmake files currently compile all of KJ in lite mode
(and a subset of capnp). We should adjust them to only build the "lite"
subset of KJ, which is exactly the set of KJ files that are included in the
MSVC project; the rest should only be included in non-lite mode.

Let's get this done and plan to release 0.5.0 in the first week of
December. :)

-Kenton
Post by Kenton Varda
Hi all,
1) MinGW can now compile all lite-mode tests as well as a working capnp
./configure --disable-shared CXXFLAGS='-static-libgcc -static-libstdc++'
./configure --host=x86_64-w64-mingw32 --with-external-capnp
--disable-shared CXXFLAGS='-static-libgcc -static-libstdc++'
2) I just pushed a basic MSVC project file that covers the parts of KJ
needed by capnp-lite (including respective tests).
- Only KJ covered so far. Going to start on capnp next.
- I only bothered to port the parts of KJ needed by capnp-lite, which
array, common, debug, exception, io, memory, string, miniposix (new).
- You'll need to run setup-autotools.sh in cygwin -- or download gtest
manually -- before the project file will work.
- Although I didn't directly pull Bryan's code, I had it open in a window
as I did this, and took a bunch of solutions from it. Thanks, Bryan! I've
added you to the CONTRIBUTORS list.
One thing I haven't figured out is cmake on Windows. I tried using cmake
to build MSVC projects and it simply didn't work. It looks like it was
trying to build project files for MSVC 2013 and those failed with 2015, but
cmake didn't give MSVC an opportunity to run the project updater flow
before failing out.
Since I don't know cmake, I feel like I'm flailing in the dark here. Could
someone who knows cmake look into how to make it work with VS2015 Preview
and write up some instructions? We should also modify the cmake files to
only compile above-mentioned subset of KJ in lite mode. (We should probably
do the same with Makefile.am, but that's not as important.)
Thanks!
-Kenton
Post by Kenton Varda
Looks like not much has changed since the last CTP. Expression SFINAE and
incomplete constexpr are going to continue to be a problem. :/
In good news, I got the capnp compiler building on MinGW yesterday, and
am now working on eliminating the dependency on winpthreads.
Cross-compiling to MinGW on Linux and then testing on Wine was surprisingly
easy. I wonder if I can get cl.exe to run in Wine... would make it much
easier to integrate Windows testing into my workflow.
-Kenton
Post by David Anes
http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17-features-in-vs-2015-preview.aspx
Hope this helps.
Post by Kenton Varda
Dang, I was trying to be careful to use only type-based SFINAE in the
hopes that it would make MSVC happy. Doesn't the standard library do this
kind of thing a lot, e.g. in type_traits?
I don't know off the top of my head what to do about this. I will
probably start playing with it myself soon. Was planning to install MSVS'15
Preview this week or next to take a look.
-Kenton
Post by Bryan Boreham
I got back to looking at this again, but it seems that a change in
'capnp::_::kindSfinae': ambiguous call to overloaded function
capnproto\c++\src\capnp\common.h(110): note: could be 'uint64_t
capnp::_::kindSfinae<T>(...)'
capnproto\c++\src\capnp\common.h(109): note: or 'uint32_t
capnp::_::kindSfinae<T,schemas::EnumInfo<T>::IsEnum>(int)'
capnproto\c++\src\capnp\common.h(108): note: or 'uint16_t
capnp::_::kindSfinae<T,T::_capnpPrivate::IsInterface>(int)'
capnproto\c++\src\capnp\common.h(107): note: or 'uint8_t
capnp::_::kindSfinae<T,T::_capnpPrivate::IsStruct>(int)'
capnproto\c++\src\capnp\common.h(112): note: while trying to match the
argument list '(int)'
template <typename T> struct ListElementType_<List<T>> { typedef T Type; };
Seems MSVC is being a bit eager trying to figure out what it all means
before anyone came up with a T yet.
I spent some time playing around trying different ways to code it, but
didn't really get anywhere.
Do you have any suggestions?
Regards,
Bryan
Post by Kenton Varda
Hi Bryan,
The changes look acceptable although some cleanup is obviously needed.
It occurs to me that most of the KJ library is actually not used by
lite mode Cap'n Proto and therefore can be skipped. Sorry, I should have
gone through this list earlier!
- kj/async*: Only used by RPC.
- kj/parse, kj/tuple, kj/oneof: Only used by schema parser, i.e. the
compiler, which we'll build with MinGW.
- kj/main: Only used by command-line tools, i.e. again the compiler.
- kj/refcount: Used by RPC and compiler.
- kj/mutex, kj/threadlocal, kj/arena: Used by SchemaLoader, compiler,
and RPC -- none of which is in lite mode.
- kj/string-tree: Not used in lite mode.
-Kenton
Post by Bryan Boreham
Hi Kenton, sorry for long pause.
I have installed the latest MSVC CTP, and it is a bit tighter on
some things than the one I was using before. I fixed up a few things, so
the code at https://github.com/bboreham/capnproto in branch
bryan-vs14 compiles the 'kj' directory; I haven't finished looking at
'capnproto'.
From what I see, the LITE mode is only in 'capnproto', so at least
some changes in 'kj' are needed to build with MSVC. I haven't had time to
analyse what the sweet-spot between the scale of changes I made and the
minimum possible in LITE mode.
I haven't done a pull request yet as it's still unfinished. Ideally
I would split the changes into a few parts, e.g. keep the MSVC 'solution'
and 'project' files separate.
I think it's worth you taking a look over the changes - start in
kj/common.h, which will give you a feel, and then say whether you really
want this in 0.5.
Regards,
Bryan
Post by Kenton Varda
Hi all,
I would like for version 0.5.0 to include basic MSVC support.
Bryan, since you've already investigated a lot of this, tell me if
the following makes sense.
I think that it's going to be tough to properly support the
reflection (schema and dynamic) APIs without full constexpr and expression
SFINAE support -- two things that MSVC is still missing. This is
particularly true after my recent changes to support generics, which
required doing some more expression SFINAE tricks.
However, I think it would be acceptable to simply disable
reflection in MSVC for now. Most people do not actually need it. Almost all
of the template tricks in the codebase are reflection-related -- even
"kind<T>()".
Protobufs has long supported something called "lite mode" which
drops support for everything reflection-related. It turns out to be quite
usable in practice. Cap'n Proto doesn't have a lot of the problems that
made lite mode necessary for Protobufs, but we could do something very
similar for MSVC support.
Specific proposal: When macro CAPNP_LITE is defined to 1, all
reflection-related stuff will be skipped, and reflection-specific headers
will error out if included. On MSVC, we'll enable lite mode by default
(until the compiler catches up), but people could also define it on other
compilers to get a leaner library.
Note that if we don't support reflection, this implies we don't
support stringification (printing human-readable representations of
messages), because it relies on reflection. This kind of sucks, but it's a
problem Protobuf-lite has as well, and people get by. We could possibly
solve it by code-generating stringification methods instead, though that of
course means code bloat.
Thoughts?
If this seems good, then I'm going to go ahead and start inserting
CAPNP_LITE ifdefs.
We will need MinGW support in order to build the compiler binary
(since that definitely requires reflection). Joshua, you already did some
work in this direction. Care to continue that?
Bryan, once the CAPNP_LITE stuff is in, are you up for doing
another pass of getting it to work in MSVC and send me a pull request? BTW,
note that we actually have cmake support now, so let's make sure it works
for the MSVC build.
-Kenton
--
You received this message because you are subscribed to the Google
Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it,
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google
Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google
Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/capnproto.
--
David "kraptor" Anes Alcolea
<http://twitter.com/simlaps>
* linkedin.com/in/davidanes
* kraptor.com | simlaps.com | 900grados.es
<http://simlaps.com>
--
You received this message because you are subscribed to the Google
Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Phil
2014-11-24 12:39:11 UTC
Permalink
Post by Kenton Varda
One thing I haven't figured out is cmake on Windows. I tried using cmake
to build MSVC projects and it simply didn't work. It looks like it was
trying to build project files for MSVC 2013 and those failed with 2015, but
cmake didn't give MSVC an opportunity to run the project updater flow
before failing out.
Which version of CMake are you using to generate the project files? CMake
3.1-rc2 supports generating Visual Studio 14 (aka 2015) project files.

I've pushed a couple of commits into my 'cmake' branch <
https://github.com/pqu/capnproto/tree/cmake> to update the kj build for
CAPNP_LITE and compiler flags for MSVC. It successfully builds the
libraries (you may want to tweak the warning level), but I don't have a
MinGW environment setup to try building and running the tests.

Phil
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Klaim - Joël Lamotte
2014-11-25 00:11:14 UTC
Permalink
Post by Phil
Which version of CMake are you using to generate the project files? CMake
3.1-rc2 supports generating Visual Studio 14 (aka 2015) project files.
Yeah before this version CMake can only generate for VS2013 so VS2015 tries
to upgrade the project on startup but it should work normally too once done.
Kenton your problem with CMake is strange, do you have a specific CMake
error when generating the VS2013 projects?
Or maybe just ignore that and add in the CMake scripts that the minimal
MSVC version is VC14 (VS2015).

I'll try right now Phil's changes with CMake 3.1-rc2 and VS2015 Preview.
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Klaim - Joël Lamotte
2014-11-25 00:24:59 UTC
Permalink
Post by Klaim - Joël Lamotte
I'll try right now Phil's changes with CMake 3.1-rc2 and VS2015 Preview.
I only tried to compile in 32bit, compilation seems to fail because of
flags that should not be there
(trying to compile ALL_BUILD target) :

1>------ Build started: Project: ZERO_CHECK, Configuration: Debug Win32
------
1> Checking Build System
1> CMake does not need to re-run because
E:/SDK/captainproto/build-capnproto_cmake_msvc-32/CMakeFiles/generate.stamp
is up-to-date.
1> CMake does not need to re-run because
E:/SDK/captainproto/build-capnproto_cmake_msvc-32/c++/CMakeFiles/generate.stamp
is up-to-date.
1> CMake does not need to re-run because
E:/SDK/captainproto/build-capnproto_cmake_msvc-32/c++/src/CMakeFiles/generate.stamp
is up-to-date.
1> CMake does not need to re-run because
E:/SDK/captainproto/build-capnproto_cmake_msvc-32/c++/src/kj/CMakeFiles/generate.stamp
is up-to-date.
1> CMake does not need to re-run because
E:/SDK/captainproto/build-capnproto_cmake_msvc-32/c++/src/capnp/CMakeFiles/generate.stamp
is up-to-date.
2>------ Build started: Project: kj, Configuration: Debug Win32 ------
3>------ Build started: Project: gtest_build, Configuration: Debug Win32
------
2> Building Custom Rule
E:/SDK/captainproto/capnproto_cmake_msvc/c++/src/kj/CMakeLists.txt
2> CMake does not need to re-run because
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\kj\CMakeFiles\generate.stamp
is up-to-date.
2>cl : Command line error D8021: invalid numeric argument '/Wextra'
4>------ Build started: Project: capnp, Configuration: Debug Win32 ------
3> Building Custom Rule
E:/SDK/captainproto/capnproto_cmake_msvc/c++/src/CMakeLists.txt
5>------ Build started: Project: kj-async, Configuration: Debug Win32 ------
3> CMake does not need to re-run because
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\CMakeFiles\generate.stamp
is up-to-date.
3> Creating directories for 'gtest_build'
4> Building Custom Rule
E:/SDK/captainproto/capnproto_cmake_msvc/c++/src/capnp/CMakeLists.txt
4> CMake does not need to re-run because
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\capnp\CMakeFiles\generate.stamp
is up-to-date.
3> Performing download step (download, verify and extract) for
'gtest_build'
4>cl : Command line error D8021: invalid numeric argument '/Wextra'
5> Building Custom Rule
E:/SDK/captainproto/capnproto_cmake_msvc/c++/src/kj/CMakeLists.txt
6>------ Build started: Project: capnpc, Configuration: Debug Win32 ------
7>------ Build started: Project: capnpc_cpp, Configuration: Debug Win32
------
3> -- verifying file...
5> CMake does not need to re-run because
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\kj\CMakeFiles\generate.stamp
is up-to-date.
3>
file='E:/SDK/captainproto/build-capnproto_cmake_msvc-32/c++/src/gtest_build-prefix/src/gtest-1.7.0.zip'
3> -- verifying file... done
3> -- extracting...
3>
src='E:/SDK/captainproto/build-capnproto_cmake_msvc-32/c++/src/gtest_build-prefix/src/gtest-1.7.0.zip'
3>
dst='E:/SDK/captainproto/build-capnproto_cmake_msvc-32/c++/src/gtest_build-prefix/src/gtest_build'
3> -- extracting... [tar xfz]
5>cl : Command line error D8021: invalid numeric argument '/Wextra'
6> Building Custom Rule
E:/SDK/captainproto/capnproto_cmake_msvc/c++/src/capnp/CMakeLists.txt
6> CMake does not need to re-run because
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\capnp\CMakeFiles\generate.stamp
is up-to-date.
8>------ Build started: Project: capnp-rpc, Configuration: Debug Win32
------
6>cl : Command line error D8021: invalid numeric argument '/Wextra'
7> Building Custom Rule
E:/SDK/captainproto/capnproto_cmake_msvc/c++/src/capnp/CMakeLists.txt
7> CMake does not need to re-run because
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\capnp\CMakeFiles\generate.stamp
is up-to-date.
9>------ Build started: Project: capnp_tool, Configuration: Debug Win32
------
8> Building Custom Rule
E:/SDK/captainproto/capnproto_cmake_msvc/c++/src/capnp/CMakeLists.txt
8> CMake does not need to re-run because
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\capnp\CMakeFiles\generate.stamp
is up-to-date.
7>cl : Command line error D8021: invalid numeric argument '/Wextra'
9> Building Custom Rule
E:/SDK/captainproto/capnproto_cmake_msvc/c++/src/capnp/CMakeLists.txt
10>------ Build started: Project: capnp-evolution-tests, Configuration:
Debug Win32 ------
9> CMake does not need to re-run because
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\capnp\CMakeFiles\generate.stamp
is up-to-date.
8>cl : Command line error D8021: invalid numeric argument '/Wextra'
11>------ Build started: Project: capnpc_capnp, Configuration: Debug Win32
------
10> Building Custom Rule
E:/SDK/captainproto/capnproto_cmake_msvc/c++/src/capnp/CMakeLists.txt
9>cl : Command line error D8021: invalid numeric argument '/Wextra'
10> CMake does not need to re-run because
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\capnp\CMakeFiles\generate.stamp
is up-to-date.
11> Building Custom Rule
E:/SDK/captainproto/capnproto_cmake_msvc/c++/src/capnp/CMakeLists.txt
11> CMake does not need to re-run because
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\capnp\CMakeFiles\generate.stamp
is up-to-date.
10>cl : Command line error D8021: invalid numeric argument '/Wextra'
11>cl : Command line error D8021: invalid numeric argument '/Wextra'
3> -- extracting... [analysis]
3> -- extracting... [rename]
3> -- extracting... [clean up]
3> -- extracting... done
3> No update step for 'gtest_build'
3> No patch step for 'gtest_build'
3> Performing configure step for 'gtest_build'
3> -- Configuring done
3> -- Generating done
3> -- Build files have been written to:
E:/SDK/captainproto/build-capnproto_cmake_msvc-32/c++/src/gtest_build-prefix/src/gtest_build-build
3> Performing build step for 'gtest_build'
3> Microsoft (R) Build Engine version 14.0.22310.1
3> Copyright (C) Microsoft Corporation. All rights reserved.
3>
3> Build started 2014-11-25 01:15:22.
3> The target "AfterGenerateAppxManifest" listed in an AfterTargets
attribute at "C:\Program Files
(x86)\MSBuild\Microsoft\.NetNative\Microsoft.NetNative.targets (47,11)"
does not exist in the project, and will be ignored.
3> The target "AfterGenerateAppxManifest" listed in an AfterTargets
attribute at "C:\Program Files
(x86)\MSBuild\Microsoft\.NetNative\Microsoft.NetNative.targets (94,11)"
does not exist in the project, and will be ignored.
3> The target "AfterGenerateAppxManifest" listed in an AfterTargets
attribute at "C:\Program Files
(x86)\MSBuild\Microsoft\.NetNative\Microsoft.NetNative.targets (47,11)"
does not exist in the project, and will be ignored.
3> The target "AfterGenerateAppxManifest" listed in an AfterTargets
attribute at "C:\Program Files
(x86)\MSBuild\Microsoft\.NetNative\Microsoft.NetNative.targets (94,11)"
does not exist in the project, and will be ignored.
3> Project
"E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\gtest_build-prefix\src\gtest_build-build\ALL_BUILD.vcxproj"
on node 1 (default targets).
3> Project
"E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\gtest_build-prefix\src\gtest_build-build\ALL_BUILD.vcxproj"
(1) is building
"E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\gtest_build-prefix\src\gtest_build-build\ZERO_CHECK.vcxproj"
(2) on node 1 (default targets).
3> InitializeBuildStatus:
3> Creating "Win32\Debug\ZERO_CHECK\ZERO_CHECK.tlog\unsuccessfulbuild"
because "AlwaysCreate" was specified.
3> CustomBuild:
3> All outputs are up-to-date.
3> FinalizeBuildStatus:
3> Deleting file
"Win32\Debug\ZERO_CHECK\ZERO_CHECK.tlog\unsuccessfulbuild".
3> Touching
"Win32\Debug\ZERO_CHECK\ZERO_CHECK.tlog\ZERO_CHECK.lastbuildstate".
3> Done Building Project
"E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\gtest_build-prefix\src\gtest_build-build\ZERO_CHECK.vcxproj"
(default targets).
3> The target "AfterGenerateAppxManifest" listed in an AfterTargets
attribute at "C:\Program Files
(x86)\MSBuild\Microsoft\.NetNative\Microsoft.NetNative.targets (47,11)"
does not exist in the project, and will be ignored.
3> The target "AfterGenerateAppxManifest" listed in an AfterTargets
attribute at "C:\Program Files
(x86)\MSBuild\Microsoft\.NetNative\Microsoft.NetNative.targets (94,11)"
does not exist in the project, and will be ignored.
3> Project
"E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\gtest_build-prefix\src\gtest_build-build\ALL_BUILD.vcxproj"
(1) is building
"E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\gtest_build-prefix\src\gtest_build-build\gtest.vcxproj"
(3) on node 1 (default targets).
3> InitializeBuildStatus:
3> Creating "gtest.dir\Debug\gtest.tlog\unsuccessfulbuild" because
"AlwaysCreate" was specified.
3> CustomBuild:
3> All outputs are up-to-date.
3> ClCompile:
3> All outputs are up-to-date.
3> Lib:
3> All outputs are up-to-date.
3> gtest.vcxproj ->
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\gtest_build-prefix\src\gtest_build-build\Debug\gtest.lib
3> FinalizeBuildStatus:
3> Deleting file "gtest.dir\Debug\gtest.tlog\unsuccessfulbuild".
3> Touching "gtest.dir\Debug\gtest.tlog\gtest.lastbuildstate".
3> Done Building Project
"E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\gtest_build-prefix\src\gtest_build-build\gtest.vcxproj"
(default targets).
3> The target "AfterGenerateAppxManifest" listed in an AfterTargets
attribute at "C:\Program Files
(x86)\MSBuild\Microsoft\.NetNative\Microsoft.NetNative.targets (47,11)"
does not exist in the project, and will be ignored.
3> The target "AfterGenerateAppxManifest" listed in an AfterTargets
attribute at "C:\Program Files
(x86)\MSBuild\Microsoft\.NetNative\Microsoft.NetNative.targets (94,11)"
does not exist in the project, and will be ignored.
3> Project
"E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\gtest_build-prefix\src\gtest_build-build\ALL_BUILD.vcxproj"
(1) is building
"E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\gtest_build-prefix\src\gtest_build-build\gtest_main.vcxproj"
(4) on node 1 (default targets).
3> InitializeBuildStatus:
3> Creating "gtest_main.dir\Debug\gtest_main.tlog\unsuccessfulbuild"
because "AlwaysCreate" was specified.
3> CustomBuild:
3> All outputs are up-to-date.
3> ClCompile:
3> All outputs are up-to-date.
3> Lib:
3> All outputs are up-to-date.
3> gtest_main.vcxproj ->
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\gtest_build-prefix\src\gtest_build-build\Debug\gtest_main.lib
3> FinalizeBuildStatus:
3> Deleting file
"gtest_main.dir\Debug\gtest_main.tlog\unsuccessfulbuild".
3> Touching
"gtest_main.dir\Debug\gtest_main.tlog\gtest_main.lastbuildstate".
3> Done Building Project
"E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\gtest_build-prefix\src\gtest_build-build\gtest_main.vcxproj"
(default targets).
3> InitializeBuildStatus:
3> Creating "Win32\Debug\ALL_BUILD\ALL_BUILD.tlog\unsuccessfulbuild"
because "AlwaysCreate" was specified.
3> CustomBuild:
3> All outputs are up-to-date.
3> FinalizeBuildStatus:
3> Deleting file
"Win32\Debug\ALL_BUILD\ALL_BUILD.tlog\unsuccessfulbuild".
3> Touching
"Win32\Debug\ALL_BUILD\ALL_BUILD.tlog\ALL_BUILD.lastbuildstate".
3> Done Building Project
"E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\gtest_build-prefix\src\gtest_build-build\ALL_BUILD.vcxproj"
(default targets).
3>
3> Build succeeded.
3> 0 Warning(s)
3> 0 Error(s)
3>
3> Time Elapsed 00:00:00.50
3> No install step for 'gtest_build'
3> Completed 'gtest_build'
12>------ Build started: Project: capnp-heavy-tests, Configuration: Debug
Win32 ------
13>------ Build started: Project: capnp-tests, Configuration: Debug Win32
------
14>------ Build started: Project: kj-heavy-tests, Configuration: Debug
Win32 ------
15>------ Build started: Project: kj-tests, Configuration: Debug Win32
------
15> Building Custom Rule
E:/SDK/captainproto/capnproto_cmake_msvc/c++/src/kj/CMakeLists.txt
13> Building Custom Rule
E:/SDK/captainproto/capnproto_cmake_msvc/c++/src/capnp/CMakeLists.txt
14> Building Custom Rule
E:/SDK/captainproto/capnproto_cmake_msvc/c++/src/kj/CMakeLists.txt
12> Building Custom Rule
E:/SDK/captainproto/capnproto_cmake_msvc/c++/src/capnp/CMakeLists.txt
15> CMake does not need to re-run because
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\kj\CMakeFiles\generate.stamp
is up-to-date.
14> CMake does not need to re-run because
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\kj\CMakeFiles\generate.stamp
is up-to-date.
13> CMake does not need to re-run because
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\capnp\CMakeFiles\generate.stamp
is up-to-date.
12> CMake does not need to re-run because
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\c++\src\capnp\CMakeFiles\generate.stamp
is up-to-date.
13> Compiling Cap'n Proto schema test.capnp
12> Compiling Cap'n Proto schema test.capnp
13> 'Debug\capnp.exe' is not recognized as an internal or external command,
13> operable program or batch file.
12> 'Debug\capnp.exe' is not recognized as an internal or external command,
12> operable program or batch file.
13>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(170,5):
error MSB6006: "cmd.exe" exited with code 9009.
12>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(170,5):
error MSB6006: "cmd.exe" exited with code 9009.
14>cl : Command line error D8021: invalid numeric argument '/Wextra'
15>cl : Command line error D8021: invalid numeric argument '/Wextra'
16>------ Build started: Project: ALL_BUILD, Configuration: Debug Win32
------
16> Building Custom Rule
E:/SDK/captainproto/capnproto_cmake_msvc/CMakeLists.txt
16> CMake does not need to re-run because
E:\SDK\captainproto\build-capnproto_cmake_msvc-32\CMakeFiles\generate.stamp
is up-to-date.
========== Build: 3 succeeded, 13 failed, 0 up-to-date, 0 skipped ==========



I did it just by cloning the repo and running CMake.
As I used the CMake GUI, I have a view of all the variables.
Also note that:

- the CMake variables for CapNP are all "not found", so maybe there is
something wrong there;
- A LOT of CMake variables don't have the project's prefix, which is
highly wrong and problematic
(in particular in my project where I inject my dependencies target into
my own CMake scripts
for helping with debugging)
It's CMake's recommendations that suggest to always prefix projects
options to help with multi-projects contexts.

Now I tried with the light version:
- I had to turn off BUILD_TESTING, which was clear (except the missing
prefix in the name);
- on compilation I still got the wrong argument error:

1>------ Build started: Project: ZERO_CHECK, Configuration: Debug Win32
------
2>------ Build started: Project: kj, Configuration: Debug Win32 ------
2>cl : Command line error D8021: invalid numeric argument '/Wextra'
3>------ Build started: Project: capnp, Configuration: Debug Win32 ------
3>cl : Command line error D8021: invalid numeric argument '/Wextra'
========== Build: 1 succeeded, 2 failed, 0 up-to-date, 0 skipped ==========


I have to go to sleep now but I can try again tomorrow at work and at home.
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Phil
2014-11-25 09:53:20 UTC
Permalink
Post by Klaim - Joël Lamotte
2>cl : Command line error D8021: invalid numeric argument '/Wextra'
Are you sure you've pulled from my 'cmake' branch? It looks like the
"if(MSVC)" tests didn't work/aren't there.
Post by Klaim - Joël Lamotte
- the CMake variables for CapNP are all "not found", so maybe there is
something wrong there;
These variables are used to locate the capnp compiler when building the
tests without building the compiler too. You should be prevented from
generating the project files if you're trying to build a configuration that
needs them set.
Post by Klaim - Joël Lamotte
- A LOT of CMake variables don't have the project's prefix, which is
highly wrong and problematic
(in particular in my project where I inject my dependencies target into
my own CMake scripts
for helping with debugging)
It's CMake's recommendations that suggest to always prefix projects
options to help with multi-projects contexts.
I'm a little suspicious of this. I haven't seen (and can't find) a CMake
style guide that makes this recommendation (aside from the one for writing
find_package modules) and CMake itself isn't particularly consistent---for
example, the BUILD_TESTING variable comes from CTest. Multiple CMake
projects (particularly dependencies) are usually tied together with
ExternalProject/the package registry/exported targets to prevent
conflicting variables or targets.
Post by Klaim - Joël Lamotte
- I had to turn off BUILD_TESTING, which was clear (except the missing
prefix in the name);
Phil
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Klaim - Joël Lamotte
2014-11-25 11:28:08 UTC
Permalink
Post by Phil
Post by Klaim - Joël Lamotte
2>cl : Command line error D8021: invalid numeric argument '/Wextra'
Are you sure you've pulled from my 'cmake' branch? It looks like the
"if(MSVC)" tests didn't work/aren't there.
I might have done it wrong indeed, I was on the right branch on the github
page but didn't think to check the branch
in the cloned repo. I'll try again here at work in a few hours.
Post by Phil
Post by Klaim - Joël Lamotte
- the CMake variables for CapNP are all "not found", so maybe there is
something wrong there;
These variables are used to locate the capnp compiler when building the
tests without building the compiler too. You should be prevented from
generating the project files if you're trying to build a configuration that
needs them set.
I see. The way I do in my case is to generate the targets and then add
automated scripts to my own targets
which knows where the compiler is. Basically custom stuffs, so this is not
a problem I guess.
Post by Phil
- A LOT of CMake variables don't have the project's prefix, which is
Post by Klaim - Joël Lamotte
highly wrong and problematic
(in particular in my project where I inject my dependencies target
into my own CMake scripts
for helping with debugging)
It's CMake's recommendations that suggest to always prefix projects
options to help with multi-projects contexts.
I'm a little suspicious of this. I haven't seen (and can't find) a CMake
style guide that makes this recommendation (aside from the one for writing
find_package modules) and CMake itself isn't particularly consistent---for
example, the BUILD_TESTING variable comes from CTest. Multiple CMake
projects (particularly dependencies) are usually tied together with
ExternalProject/the package registry/exported targets to prevent
conflicting variables or targets.
I was thinking about both the find module recommendations (which is
directly linked as the options are the same)
and current practice:

1. Look at other well known projects using CMake and you'll see that
project-prefix is the usual way options are named;
2. Let's say you have one project in a repo and want the repo (or an
associated dependency repo)
to contain a copy of some dependencies at a specific version (for
whatever reason, maybe because of patches, or
licenses issues or whatever: this is not the most common case but it
happens).
If all the dependencies use non-prefixed options, then option names
can enter in collision.
The usual way to setup such context is that the project have a
CMakeLists.txt which use add_subdirectory(some/dependency)
to generate the dependencies targets, then have his own targets link with
targets.
That way, for example in visual studio, you end up with all your
dependencies
visible, which is useful in some case (but not all, of course).
I'm doing things like that for my project that I want to use capnp for.

In any way, even CMAke and Capnp dependencies have prefixes for their
options and it's very hard to figure out
what options are for what project if there is no prefixes.
Post by Phil
Post by Klaim - Joël Lamotte
- I had to turn off BUILD_TESTING, which was clear (except the missing
prefix in the name);
Phil
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/capnproto.
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Klaim - Joël Lamotte
2014-11-25 12:44:32 UTC
Permalink
I have generated with the right branch and didn' see any error.
Maybe making CAPNP_LITE on by default with MSVC would be better than making
me
discovering it and changing it.

Other than the option naming issue (which is already a problem even when
not trying
to integrate capnp with my own project),
there is tons of warning.
I know VS2015 have a lot more warning checks than previous verisons,
butI'm surprised that it is pointing at non-referenced code. It's a library
so it
feels normal, so I was wondering if you activated a higher warning mode
than the default?

Anyway, everything compiles. I didn't try to run anything yet.
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Phil
2014-11-26 02:44:09 UTC
Permalink
Post by Klaim - Joël Lamotte
2. Let's say you have one project in a repo and want the repo (or an
associated dependency repo)
to contain a copy of some dependencies at a specific version (for
whatever reason, maybe because of patches, or
licenses issues or whatever: this is not the most common case but it
happens).
If all the dependencies use non-prefixed options, then option names
can enter in collision.
The usual way to setup such context is that the project have a
CMakeLists.txt which use add_subdirectory(some/dependency)
to generate the dependencies targets, then have his own targets link with
targets.
When `add_subdirectory()` works, it's great; but it quickly breaks with
larger projects and external dependencies. For example: Cap'n Proto has a
dependency on googletest. If your project also has a dependency on
googletest and you import both it and Cap'n Proto with
`add_subdirectory()`, CMake will fail when it sees two "gtest" targets.

When you don't control the project you're adding with `add_subdirectory()`,
it can unintentionally break the build because its authors can't anticipate
the scope you're importing it into. CMake has several tools and patterns
for isolating your project's build from those of its dependencies:
https://coderwall.com/p/y3zzbq/.

(Also, some of Cap'n Proto's CMake options were named to be consistent with
the autotools build. In general, I agree with prefixing to aid clarity.)

Phil
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Klaim - Joël Lamotte
2014-11-26 09:23:06 UTC
Permalink
Post by Phil
Post by Klaim - Joël Lamotte
2. Let's say you have one project in a repo and want the repo (or an
associated dependency repo)
to contain a copy of some dependencies at a specific version (for
whatever reason, maybe because of patches, or
licenses issues or whatever: this is not the most common case but it
happens).
If all the dependencies use non-prefixed options, then option names
can enter in collision.
The usual way to setup such context is that the project have a
CMakeLists.txt which use add_subdirectory(some/dependency)
to generate the dependencies targets, then have his own targets link with
targets.
When `add_subdirectory()` works, it's great; but it quickly breaks with
larger projects and external dependencies. For example: Cap'n Proto has a
dependency on googletest. If your project also has a dependency on
googletest and you import both it and Cap'n Proto with
`add_subdirectory()`, CMake will fail when it sees two "gtest" targets.
Yes I have hit issues like this before but it's easy to fix most of the
time by providing your own gtest, maybe patching the lib CMake scripts
or even just using an option if the developer already provide it. However
you are right that it's not the best way to use CMake,
I just don't know a better way to make sure I have quick access to my
dependencies sources (which provide insanely useful in the past).
Post by Phil
When you don't control the project you're adding with
`add_subdirectory()`, it can unintentionally break the build because its
authors can't anticipate the scope you're importing it into. CMake has
several tools and patterns for isolating your project's build from those of
its dependencies: https://coderwall.com/p/y3zzbq/.
I know about ExternalProject* but it don't seem to always solve my problem.
I have plans to try switching to it fully, see how it goes,
but getting dependencies sources in the final solution (for vs) is still a
problem.
Anywya, it's getting off-topic I guess.
Post by Phil
(Also, some of Cap'n Proto's CMake options were named to be consistent
with the autotools build. In general, I agree with prefixing to aid
clarity.)
I see.
Is there a reason to keep the autotools names now that there is a potential
switch to CMake?
Post by Phil
Phil
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Kenton Varda
2014-11-23 06:00:48 UTC
Permalink
Post by Bryan Boreham
I got back to looking at this again, but it seems that a change in
'capnp::_::kindSfinae': ambiguous call to overloaded function
capnproto\c++\src\capnp\common.h(110): note: could be 'uint64_t
capnp::_::kindSfinae<T>(...)'
capnproto\c++\src\capnp\common.h(109): note: or 'uint32_t
capnp::_::kindSfinae<T,schemas::EnumInfo<T>::IsEnum>(int)'
capnproto\c++\src\capnp\common.h(108): note: or 'uint16_t
capnp::_::kindSfinae<T,T::_capnpPrivate::IsInterface>(int)'
capnproto\c++\src\capnp\common.h(107): note: or 'uint8_t
capnp::_::kindSfinae<T,T::_capnpPrivate::IsStruct>(int)'
capnproto\c++\src\capnp\common.h(112): note: while trying to match the
argument list '(int)'
I managed to work around this. The trick is to move the sizeof() statement
out into a separate template.

http://stackoverflow.com/questions/4806238/cant-compile-sfinae-in-visual-studio-10

However, now I have a weird problem:

template <typename T, Kind k = CAPNP_KIND(T)>
struct List;

capnp\common.h(167): error C2065: 'T': undeclared identifier

It seems MSVC refuses to let me use the first parameter of a template
inside the default value expression for the second parameter, if the second
parameter is a value (not a type). That is:

THIS WORKS:
template <typename T, typename U = _::Kind_<T>>
struct List;

THIS FAILS:
template <typename T, Kind k = _::Kind_<T>::kind>
struct List;

Bryan, did you ever run into this? How did you solve it?

-Kenton
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Bryan Boreham
2014-11-23 23:34:54 UTC
Permalink
Post by Kenton Varda
Post by Bryan Boreham
I got back to looking at this again, but it seems that a change in
'capnp::_::kindSfinae': ambiguous call to overloaded function
capnproto\c++\src\capnp\common.h(110): note: could be 'uint64_t
capnp::_::kindSfinae<T>(...)'
capnproto\c++\src\capnp\common.h(109): note: or 'uint32_t
capnp::_::kindSfinae<T,schemas::EnumInfo<T>::IsEnum>(int)'
capnproto\c++\src\capnp\common.h(108): note: or 'uint16_t
capnp::_::kindSfinae<T,T::_capnpPrivate::IsInterface>(int)'
capnproto\c++\src\capnp\common.h(107): note: or 'uint8_t
capnp::_::kindSfinae<T,T::_capnpPrivate::IsStruct>(int)'
capnproto\c++\src\capnp\common.h(112): note: while trying to match the
argument list '(int)'
I managed to work around this. The trick is to move the sizeof() statement
out into a separate template.
http://stackoverflow.com/questions/4806238/cant-compile-sfinae-in-visual-studio-10
template <typename T, Kind k = CAPNP_KIND(T)>
struct List;
capnp\common.h(167): error C2065: 'T': undeclared identifier
It seems MSVC refuses to let me use the first parameter of a template
inside the default value expression for the second parameter, if the second
template <typename T, typename U = _::Kind_<T>>
struct List;
template <typename T, Kind k = _::Kind_<T>::kind>
struct List;
Bryan, did you ever run into this? How did you solve it?
Yes, of course. I added the following declaration:

template <typename T, Kind k> struct List {};

As of this precise moment, I cannot remember the complete line of reasoning
that led to this. Something about MSVC being unable to grok a 'friend'
declaration elsewhere.

Hope this helps,

Bryan
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Kenton Varda
2014-11-24 00:00:01 UTC
Permalink
Post by Bryan Boreham
template <typename T, Kind k> struct List {};
... I am incredibly confused as to why that works, but it seems to work.
Thanks!

(I actually saw that in your code but thought that couldn't possibly have
anything to do with my problem...)

-Kenton
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+***@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.
Loading...