Thread: [Cppcms-users] cppcms build problems
Brought to you by:
artyom-beilis
Menu
▾
▴
cppcms-users
|
From: Mike A. <mi...@ax...> - 2009-11-10 14:00:58
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
First of all, I'd like to thank the work on this project. I'm very
excited to start using this.
I'm currently using Ubuntu 9.10 and trying to compile this project
(using both the release and svn head).
After installing all the dependencies (which involve specifying boost
version 1.40), it still will not compile.
I got this error:
In file included from hmac_encryptor.h:3,
from session_cookies.cpp:5:
encryptor.h:18: error: ‘uint16_t’ does not name a type
- -Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.10)
iEYEARECAAYFAkr5bPoACgkQ3wH7qi4osjgywACfS6rMRTMCm0mM1grZP1+mcCFs
5IUAoM0fGmtRxyKONGXZtuOFA+L/5K7j
=gg6F
-----END PGP SIGNATURE-----
|
|
From: Stanimir M. <sta...@zo...> - 2009-11-10 15:28:20
|
You can compile it just by adding in the session_sid.h and encryptor.h the following includes: #include <stdint.h> #include <stdio.h> That worked for me, but I am sure that after your report Artyom will fix it in the trunk too. Greetings, Stanimir On Tue, Nov 10, 2009 at 3:39 PM, Mike Axiak <mi...@ax...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > First of all, I'd like to thank the work on this project. I'm very > excited to start using this. > I'm currently using Ubuntu 9.10 and trying to compile this project > (using both the release and svn head). > After installing all the dependencies (which involve specifying boost > version 1.40), it still will not compile. > I got this error: > > In file included from hmac_encryptor.h:3, > from session_cookies.cpp:5: > encryptor.h:18: error: ‘uint16_t’ does not name a type > > > - -Mike > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.10) > > iEYEARECAAYFAkr5bPoACgkQ3wH7qi4osjgywACfS6rMRTMCm0mM1grZP1+mcCFs > 5IUAoM0fGmtRxyKONGXZtuOFA+L/5K7j > =gg6F > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > |
|
From: Artyom <art...@ya...> - 2009-11-10 15:51:18
|
> You can compile it just by adding in
> the session_sid.h and encryptor.h
> the following includes:
>
> #include <stdint.h>
> #include <stdio.h>
I see, you really need stdint.h, but do you need stdio.h?
I'll fix in trunk ASAP.
What gcc version are you using?
Artyom
|
|
From: Stanimir M. <sta...@zo...> - 2009-11-10 17:05:18
|
Mine gcc version is 4.4.1 Without stdio.h sscanf is not defined in the cppcms::encryptor constructor. Artyom, congratulations for the Boost.Locale! You have the ability to spot exactly where is the missing tool for c++ web development and most importantly you have the courage to work and implement it :) Stanimir On Tue, Nov 10, 2009 at 5:51 PM, Artyom <art...@ya...> wrote: >> You can compile it just by adding in >> the session_sid.h and encryptor.h >> the following includes: >> >> #include <stdint.h> >> #include <stdio.h> > > I see, you really need stdint.h, but do you need stdio.h? > > I'll fix in trunk ASAP. > > What gcc version are you using? > > Artyom > > > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > |
|
From: Artyom <art...@ya...> - 2009-11-10 17:36:55
|
Hello,
> Without stdio.h sscanf is not defined in the
> cppcms::encryptor constructor.
thanks, fixed in trunk.
>
> Artyom, congratulations for the Boost.Locale! You have the
> ability to
> spot exactly where is the missing tool for c++ web
> development and
> most importantly you have the courage to work and implement
> it :)
>
To be honest, this tool is not missing only in Web development.
The situation with Localization is quite bad in any areas.
In any case,
it would be extreamly helpful if Boost.Locale would be reviewed
by many eyes, and the review notes would be sent to Boost mailing
list.
Preliminary review is very important in order to make it
possible to submit the library in future for formal review
and make it included in Boost.
Thanks,
Artyom
|
|
From: Markus R. <us...@ma...> - 2009-11-10 18:31:58
|
Artyom wrote: > To be honest, this tool is not missing only in Web development. > The situation with Localization is quite bad in any areas. Wow, I am impressed what you already achieved! boost.locale is really missing - and you are doing a great job and it seems like you have a lot of experience in that field. I see that you use cmake for boost.locale - are you planning to use it for cppcms too? Some features are very convenient: - separate build directory - far less required files in root (cppcms 0.0.4 has everything in root - together with autotools this situation is not optimal) - cpack makes e.g. deb packages for local install - dependency tracking is very good - a CMakeLists.txt per directory - and best of all - cppcms could be easily copied as subproject into projects using it, without running configure twice :-) The last point is of course not very important once cppcms is available as package in major distros. Of course there are also many pros for autotools - I am just asking. thank you Markus |
|
From: Artyom <art...@ya...> - 2009-11-10 19:40:36
|
Hello,
> I see that you use cmake for boost.locale - are you
> planning to use it for
> cppcms too?
Unfortunatly I think I would have to. There is no other
way to support MSVC, I may want to in future.
> - separate build directory
No problems to do this with autotools as well.
To be honest... For me cmake is far behind autotools.
It misses lots of features:
- Even simple and frequent things like "AC_SEARCH_LIBS",
AC_TRY_COMPILE become very inconvinient.
- Support of static/shared builds, is very unfriendly.
- Switching compilers works very bad
- Documentation total crap, seriously.
- Shared Objects versioning is quite bad and non standard
- Unintall support is none.
I used CMake for Boost.Locale just because I needed MSVC support.
If libtool would support MSVC I would not think twice
I still making a usability test of CMake, because there are
lots of non-trivial things I may want to do.
CMake may be good for Windows programming but it does not fit
well in Unix world too good -- and this is my primary target
platform.
In any case I'm still checking if CMake fits my needs at all.
Bottom line, if you do not care about Windows, autotools
still are best.
Artyom
|
|
From: Markus R. <us...@ma...> - 2009-11-10 20:48:35
|
Artyom wrote: > Hello, > >> I see that you use cmake for boost.locale - are you >> planning to use it for >> cppcms too? > > Unfortunatly I think I would have to. There is no other > way to support MSVC, I may want to in future. I don't care about windows, but I still look forward to see cmake :-) >> - separate build directory > > No problems to do this with autotools as well. > > To be honest... For me cmake is far behind autotools. > It misses lots of features: > > - Even simple and frequent things like "AC_SEARCH_LIBS", > AC_TRY_COMPILE become very inconvinient. Searching for libs is very easy - if there is already support for it. It is also often done without pkg-config. Something like find_package(Boost 1.34 REQUIRED COMPONENTS thread date_time program_options regex filesystem) may be enough. For detection of boost (and many graphic libs) you can take a look at the sourcecode of performous.org. I think about 30% of their source code is cmake code - mostly checkers for many libraries. > - Support of static/shared builds, is very unfriendly. I think thats taste - I found libtool unfriendly. > - Switching compilers works very bad Ok, I have no experience on that. > - Documentation total crap, seriously. Documenation could be always improved. > - Shared Objects versioning is quite bad and non standard Isn't that the programmers job? > - Unintall support is none. Mmmh, I would say its better because you can make native packages which uninstall really clean. make uninstall is always a hassle, because it does not work on other versions than the one you used for installation. > CMake may be good for Windows programming but it does not fit > well in Unix world too good -- and this is my primary target > platform. > > In any case I'm still checking if CMake fits my needs at all. > > Bottom line, if you do not care about Windows, autotools > still are best. autotools have a greater beginners barrier. You need to learn a lot about portable shell, m4, Makefile, Makefile.in (and maybe Makefile.am)... For cmake you basically only need to learn the very easy syntax: http://www.cmake.org/cmake/help/syntax.html Btw. have you already read http://www.rrsd.com/software_development/boost/oopsla05.pdf It might help you. Markus -- http://www.markus-raab.org | Wir leben in einem gefährlichen Zeitalter: -o) | Der Mensch beherrscht die Natur, bevor er Kernel 2.6.24-1-a /\ | gelernt hat, sich selbst zu beherrschen. on a x86_64 _\_v | -- Schweitzer, Albert |
|
From: Artyom <art...@ya...> - 2009-11-10 21:32:07
|
Hello... > > Searching for libs is very easy - if there is already > support for it. It is > also often done without pkg-config. Something like > find_package(Boost 1.34 REQUIRED COMPONENTS thread > date_time program_options > regex filesystem) > may be enough. Good you mentioned it ;-) Just to make my points better. This exactly what stucks me now. I have two versions of boost, system installed 1.35 and local 1.39 I give CMake Paths to library headers and libs... It seearches... finds 1.39 but... Instead of linking with /some/path/to/libboost_foo_bar.so it links to /usr/lib/libboost_foo_bar.so Headers and libraries of different version!!! WTF?? All I need to do with auto is ./configure CXXFLAGS=-I/path/inc LIBS=-L/path/lib But CMake is smarter... Ok lets try to search a library by myself and check if I can find all I need... Find 5 libraries... but second if(X and Y and Z and T) does not work in CMake syntax... So lets write long-long tests... Ok lets check where we have socket? in libc, nls, or socket (AC_SEARCH_LIBS) there is no such thing (note it is quite different from find library)... Write long macros again. Now, lets check for simple C++0x feature "auto"... Wait a second for TRY_COMPILE I need to create a project instead of writing 3 lines. WTF??? ----------------------------- In other words... CMake is almost as useable as... handly written configure script. It is just too verbose, It is more verbose by an order of magnitude then auto* even for simple tasks you take for granted. > > Btw. have you already read > http://www.rrsd.com/software_development/boost/oopsla05.pdf > Thanks for the link... No I still didn't Artyom |
|
From: Markus R. <us...@ma...> - 2009-11-11 17:00:20
|
Artyom wrote: > Hello... > >> >> Searching for libs is very easy - if there is already >> support for it. It is >> also often done without pkg-config. Something like >> find_package(Boost 1.34 REQUIRED COMPONENTS thread >> date_time program_options >> regex filesystem) >> may be enough. > > Good you mentioned it ;-) Just to make my points better. > Ok lets try to search a library by myself and check if I can > find all I need... Find 5 libraries... but second > if(X and Y and Z and T) does not work in CMake syntax... > So lets write long-long tests... The tests are quite long, but hopefully they will be shared along projects soon or accepted into cmake core. > Ok lets check where we have socket? in libc, nls, or socket > (AC_SEARCH_LIBS) there is no such thing (note it is quite > different from find library)... > > Write long macros again. Yes > Now, lets check for simple C++0x feature "auto"... Wait a second > for TRY_COMPILE I need to create a project instead of writing > 3 lines. WTF??? You are writing for boost, so you can simply use BOOST_NO_AUTO_DECLARATIONS and don't need to write the checks yourself :-) > ----------------------------- > In other words... > > CMake is almost as useable as... handly written configure script. > It is just too verbose, It is more > verbose by an order of magnitude then auto* even for simple > tasks you take for granted. It is verbose, no question about that. I am asking myself how happy you will be with Jam :-) Markus -- http://www.markus-raab.org | Nur wer gegen den Strom schwimmt, kann zu -o) | Quelle gelangen. -- Chinesisches Kernel 2.6.24-1-a /\ | Sprichwort on a x86_64 _\_v | |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X