Hello,
As the Wt SDK is currently using winstng on Windows, I'll add a few comments
On Fri, Sep 6, 2013 at 10:25 AM, Wim Dumon <w...@emweb.be> wrote:
> 3) client-ssl-auth example shows "Login" label only without the other
>> fields
>>
> You need a client certificate, a server certificate, signed by a trusted
> CA, and configure the example as documented in the README file for this
> example to work. I adapted the example to make this message more clear.
>
Given that we build OpenSSL, maybe we can generate a CA, server and client
certificates. That way the README only needs to say "either you use the
self-signed certificates we autogenerated for you for easier testing (don't
forget to add the CA certificate to the browser store!), or you use your
own certificates"
>
>> 4) dbo-tutorials don't have .bat and source files
>>
> We'll have to fix that. I don't think they require .bat files, as they
> don't need any startup options.
>
>
IMHO it'd be nice to have the .bat, if only for symmetry with the other
examples. IIRC on Unix platforms there are shell-scripts for dbo-tutorials
too.
>
>> 8) I didn't saw GraphicsMagick libs!
>>
> It's a pain to compile from a script (they don't use cmake ;-)). It's on
> the todo list.
>
Indeed:
https://elpauer.assembla.com/spaces/winstng/tickets/2
>
>
>>
>> I suggest too:
>>
>> 1) I suggest to put all the examples (binaries and sources) under
>> "example" folder.
>>
> Problem on Windows: the .exe requires the .dll and those are automatically
> searched in the cwd. That's why we put them in bin for now.
>
>
It shouldn't be difficult to add ..\bin to PATH in run-examples.bat.cmake.
I have created a ticket for this:
https://elpauer.assembla.com/spaces/winstng/tickets/12
(although until winstng and Wt merge, this is more a Wt issue)
2) I suggest to add Dbo backend for MySQL (I prefer MariaDB instead of
>> MySQL specially there are many organizations working on leaving MySQL to
>> MariaDB).
>
> Planned, didn't want to make you wait much longer for first preview. I was
> indeed planning to use MariaDB iso MySQL (Wt supports both).
>
>
https://elpauer.assembla.com/spaces/winstng/tickets/7
> 3) I suggest to add "documentation" folder which contains on docs of Wt.
>>
> Yes, was on todo list
>
https://elpauer.assembla.com/spaces/winstng/tickets/13
>
>
>> 4) helloqt example uses Qt4 where current modern versions are Qt5 so I
>> suggest to create a new example for Qt5 or you can modify current
>> version to be able to use under Qt5
>>
> Qt4 happens to be installed on my system. Maybe we shouldn't include this
> example; the value is entirely in its source code
>
I'd say at least include the source
> 6) Because this distro guided to MSVS developers I suggest to add .sln
>> files to all examples.
>>
>
> Good suggestion, but I'm afraid it's a lot of work (unless generated by
> cmake).
>
CMake-generated VS solutions and projects will not work if you move them
from their location.
If an alternative to CMake is going to be promoted, I'd say Wt should
include a folder with the skeleton of a Makefile for GNU make, a Visual
Studio project, an Eclipse project, a CMake project with does not use
WT_ADD_EXAMPLE, and maybe others (a Qt Creator example?)
> BTW, is there any hope in the near future to create a distro for Qt
>> Creator (MinGW) instead of OR additional to MSVS (Qt Creator took one
>> min. from me to start a Wt project under Mint)?
>>
>>
> We can provide a similar package for MinGW, but I'm always confused about
> what MinGW compiler I should use for maximum compatibility. I've tested
> with two variants, as documented in the Wt wiki. Any suggestions?
>
>
Here are the factors you want to consider:
1. Mingw.org vs mingw-w64. The former uses mostly the official gcc,
while the latter implements whatever functionality they find missing (such
as Long File Support, more Windows API, etc). My advice: mingw-w64.
2. Exception handling: SJLJ (slow but crosses DLLs safely), DWARF (fast
but will crash when exceptions cross DLL barrier due to different symbol
mangling) or SEH (uses MSVC symbol mangling, therefore it's fast and safe
but it's only available for 64-bit builds because the 32-bit version of SEH
is still affected by a Borland patent). My advice: DWARF for 32-bit, SEH
for 64-bit.
3. Threading model: POSIX or Win32 API
For me, it boils down to POSIX threads or not:
- If you go for a build with POSIX threads, you'll have std::thread,
futures, etc AND depend on a POSIX compatibility layer such as WinPthread
(libwinpthread-1.dll)
- If you go for a build with Win32 threads, you will not have the POSIX
API and you will not have std::thread, futures, etc. You will not have the
dependency on WinPthread either.
You cannot mix POSIX threads and Win32 threads in the same application.
Every application build with a POSIX-threads-enabled build will depend on
libwinpthread-1.dll even if it does not use threads.
My advice: use a mingw-w64-based gcc with POSIX threads. That enables long
file support, proper exception handling (it's best on 64-bit, on 32-bit it
will cause some trouble) and std::thread. The mingwbuilds project provides
good-quality builds based on the mingw-w64 toolchain:
http://sourceforge.net/projects/mingwbuilds/
For 32-bit you want x32-4.8.1-posix-dwarf-rev4
For 64-bit you want x64-4.8.1-posix-seh-rev4
I've added this to the ticket:
https://elpauer.assembla.com/spaces/winstng/tickets/10
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
