unable to build with make on windows using 64bit mingw about boost.http HOT 9 CLOSED

I'll need more time to fix this issue. Most likely I'll only deliver the fix after the review. =(

from boost.http.

Actually, I got the same error using mingw under Linux, so maybe I don't need Windows to fix this issue and the bugfix may be delivered sooner.

from boost.http.

I haven't find a way to detect if mingw is used from CMake. There is no standard mingw distribution. Maybe I'll investigate the issue after the transition to Boost Build (Bjam).

from boost.http.

The only problem is timing. I really wanted to participate in the boost review. I tried to do so in the recent Boost.Dll review but timing didn't work out there. So my review was going to be by example, if it works out, of combining boost.dll with boost.http to provide a auto compile and auto deploy of ?handlers/services? to a boost.http web server. Cause C++ is my favorite language though I use it little professionally, I wanted to prove that I can be more productive in it than Java, C#, PHP or Ruby on Rails.

from boost.http.

combining boost.dll with boost.http to provide a auto compile and auto deploy of ?handlers/services? to a boost.http web server

You may be interested in the polymorphic adapters: https://boostgsoc14.github.io/boost.http/tutorial.html#tutorial.tutorial.runtime_based_polymorphic_abstra

from boost.http.

I would probably need more documentation and detailed examples of these polymorphic adapters. The current mentions socket which MAY be too low level when I am only interested in request (3 phase; complete header, incremental stream of body, complete request) and response. I need a whole lot more information. In case I can't participate in the review because I can't build the library. Please let me offer one thought towards the API itself.

Boost review says

1. What is your evaluation of the design?

I can't say until I can evaluate but I do have thoughts/requirements and you seem to be already considering them in order to get it into your first official release. I have been all over you site and looking at your comments on HTTP2.

Concerning your Roadmap, again just my opinion and not in any particular order, the following are the most important for the following reasons

Client-side HTTP // needed for tooling and PUT is another form of file upload
Forms and file uploads. // can't be a HTTP server library if you can't do this
World domination. // why should anyone use a library if there is no ambition to be the best it can be
HTTP/2.0 // This is CRITICAL. Server side push is a game changer and as such the API need to [PLAN TO] support the concept for when a backend becomes available or better yet emulate it until the more performant comes along. To do this API developers need to know or ENVISION how their users, developers, are going to use it. Most people who are talking about it are stuck on static content. Images won't need to be aggregated into image maps, CSS won't need stuff to de-aggregate them. While the static send these files, images along with the file I am generating is interesting, the real additional benefit comes more in terms of the dynamic content. HTTP/2.0 server side push fixes the fact that HTTP doesn't have POST redirect only GET redirect. This precipitated web sites that would better off being stateless to have to be stateful. Massive frameworks were needed to provide FLASH scope when they are enforcing PRG. Now a lot of that goes away. When there is a problem on POST, developers don't have to give a redirect with error messages and submitted data stuffed in a session, FLASH (short lived session) or database now we can push them a page with the original invalid submitted data and error messages back to the original user. What that code exactly looks like, I don't know. However, it may be best if the original code that rendered a page was partitioned such that that it doesn't know where its data came from (failed POST or original GET) and another part that knows whether it was the primary request or a push request so that it supply data to the first part via data passed into the post versus constructing it new, as in from a database, via GET parameters.

Just some thoughts, if I need to clarify anything don't hesitate to ask. I think server side push candy blurs the line, in a good way, between web server and web framework.

from boost.http.

Forms and file uploads

Just clarifying... the server can do parse forms and file uploads, but you must implement the parsing code yourself. For a web framework, this is critical for sure, for a HTTP framework, not so important (but sill important).

I don't feel the need to emphasize how the points you highlight are, but I felt the need to clarify this point.

Just some thoughts

Thanks for sharing them.

from boost.http.

The library is header-only now.

I tried to compile the example and I got similar errors:

CMakeFiles/spawn.dir/objects.a(spawn.cpp.obj): In function `boost::asio::detail::winsock_init_base::startup(boost::asio::detail::winsock_init_base::data&, unsigned char, unsigned char)':
/usr/x86_64-w64-mingw32/include/boost/asio/detail/impl/winsock_init.ipp:39: undefined reference to `__imp_WSAStartup'
CMakeFiles/spawn.dir/objects.a(spawn.cpp.obj): In function `boost::asio::detail::winsock_init_base::cleanup(boost::asio::detail::winsock_init_base::data&)':
/usr/x86_64-w64-mingw32/include/boost/asio/detail/impl/winsock_init.ipp:56: undefined reference to `__imp_WSACleanup'
CMakeFiles/spawn.dir/objects.a(spawn.cpp.obj): In function `boost::asio::detail::socket_ops::clear_last_error()':
/usr/x86_64-w64-mingw32/include/boost/asio/detail/impl/socket_ops.ipp:69: undefined reference to `__imp_WSASetLastError'
CMakeFiles/spawn.dir/objects.a(spawn.cpp.obj): In function `boost::asio::detail::socket_ops::socket(int, int, int, boost::system::error_code&)':
/usr/x86_64-w64-mingw32/include/boost/asio/detail/impl/socket_ops.ipp:1381: undefined reference to `__imp_WSASocketW'
CMakeFiles/spawn.dir/objects.a(spawn.cpp.obj): In function `unsigned long long boost::asio::detail::socket_ops::error_wrapper<unsigned long long>(unsigned long long, boost::system::error_code&
)':
/usr/x86_64-w64-mingw32/include/boost/asio/detail/impl/socket_ops.ipp:82: undefined reference to `__imp_WSAGetLastError'
CMakeFiles/spawn.dir/objects.a(spawn.cpp.obj): In function `boost::asio::detail::win_iocp_socket_service_base::start_accept_op(boost::asio::detail::win_iocp_socket_service_base::base_implement
ation_type&, bool, boost::asio::detail::socket_holder&, int, int, int, void*, unsigned long, boost::asio::detail::win_iocp_operation
...

Not sure how to fix. I suppose it's a problem with any Asio-based application you try to compile under Windows (just like you need to compile with -lm on Linux to use math functions even if it's std).

from boost.http.

Hi, the library is header-only now. Could you try to compile it again? I believe it should work now.

from boost.http.