Last 30 days

• Dec 01, 2009

  issue 48 (Compile ctemplate with MinGW GCC 4.4.0) commented on by csilvers   -   Gotcha. OK, I've modified the generator test to strip windows newlines before doing the diff. I'll check that into the SVN repository shortly, after it goes through the review process here.

  Gotcha. OK, I've modified the generator test to strip windows newlines before doing the diff. I'll check that into the SVN repository shortly, after it goes through the review process here.
• Dec 01, 2009

  issue 48 (Compile ctemplate with MinGW GCC 4.4.0) commented on by jonathan.brandmeyer   -   The difference is that libctemplate was not linked against msys-1.0.dll, so that it is a native Windows DLL that uses the standard MSVC runtime library and not the MSYS runtime library. I have attached the console output of running $ PATH=/c/Python26:$PATH make check &> errors.txt When I view this file using MSYS vi, the actual output contains extra line ending characters, displayed as ^M, when compared to the expected output.

  The difference is that libctemplate was not linked against msys-1.0.dll, so that it is a native Windows DLL that uses the standard MSVC runtime library and not the MSYS runtime library. I have attached the console output of running $ PATH=/c/Python26:$PATH make check &> errors.txt When I view this file using MSYS vi, the actual output contains extra line ending characters, displayed as ^M, when compared to the expected output.
• Nov 30, 2009

  issue 48 (Compile ctemplate with MinGW GCC 4.4.0) commented on by csilvers   -   I'm not sure I understand your last paragraph (well, not "thanks for your help," but the one before that), but if you're running the unittests under mingw, then you are using libctemplate under msys, so we'll have to get that working right. I'm still not sure what test is failing. If you can attach the complete output of your test run, that would be helpful. We can test your theory that the problem is with line endings, and if so, figure out the right fix.

  I'm not sure I understand your last paragraph (well, not "thanks for your help," but the one before that), but if you're running the unittests under mingw, then you are using libctemplate under msys, so we'll have to get that working right. I'm still not sure what test is failing. If you can attach the complete output of your test run, that would be helpful. We can test your theory that the problem is with line endings, and if so, figure out the right fix.
• Nov 27, 2009

  issue 48 (Compile ctemplate with MinGW GCC 4.4.0) commented on by jonathan.brandmeyer   -   Older MinGW did not provide either libgcc or libstdc++ as a shared library and they forced the use of SJLJ EH. MinGW GCC 4.4 is the first version to support libstdc++ as a shared library and also supports DWARF2 EH. I personally greatly prefer to use the latter, since it makes smaller executables and improves performance over SJLJ EH. libsupc++ is normally linked in by default when linking with G++. It is the GCC C++ support library. However, you run into symbol collisions if you try to link with libstdc++.dll and libstdc++.a at the same time, so you have to link with GCC and explicitly provide the right libraries. The script failure was in a state machine generation test. The error spat out two identical looking pieces of C source code and then claimed that they didn't match. I suspect that this is because of a line ending difference. If one of the examples was produced with an Msys utility, and another was produced by a native Windows program, then they might have different line endings. Alternatively, if the reference input is provided in the tarball, then the line endings in the tarball would mostly likely be Unix-style instead of Windows-style. The intent is not to actually use libctemplate under Msys - I only use Msys to run configure. The intent is to build a Windows native DLL for writing native windows programs using MinGW's port of GCC. Thanks for your help.

  Older MinGW did not provide either libgcc or libstdc++ as a shared library and they forced the use of SJLJ EH. MinGW GCC 4.4 is the first version to support libstdc++ as a shared library and also supports DWARF2 EH. I personally greatly prefer to use the latter, since it makes smaller executables and improves performance over SJLJ EH. libsupc++ is normally linked in by default when linking with G++. It is the GCC C++ support library. However, you run into symbol collisions if you try to link with libstdc++.dll and libstdc++.a at the same time, so you have to link with GCC and explicitly provide the right libraries. The script failure was in a state machine generation test. The error spat out two identical looking pieces of C source code and then claimed that they didn't match. I suspect that this is because of a line ending difference. If one of the examples was produced with an Msys utility, and another was produced by a native Windows program, then they might have different line endings. Alternatively, if the reference input is provided in the tarball, then the line endings in the tarball would mostly likely be Unix-style instead of Windows-style. The intent is not to actually use libctemplate under Msys - I only use Msys to run configure. The intent is to build a Windows native DLL for writing native windows programs using MinGW's port of GCC. Thanks for your help.
• Nov 24, 2009

  issue 48 (Compile ctemplate with MinGW GCC 4.4.0) Status changed by csilvers   -   I set to work today getting ctemplate to work under mingw. It's just about done (though against a much older mingw, it looks like, that's running gcc 3.something). I had to make a whole bunch of changes, which I'll get reviewed after thanksgiving, most likely, and then submit to the SVN repository.

  Status: Started

  I set to work today getting ctemplate to work under mingw. It's just about done (though against a much older mingw, it looks like, that's running gcc 3.something). I had to make a whole bunch of changes, which I'll get reviewed after thanksgiving, most likely, and then submit to the SVN repository.

  Status: Started
• Nov 24, 2009

  issue 50 (template_modifiers.h unused parameters) changed by csilvers   -   Sure thing. We'll do this for the next release.

  Status: Started

  Labels: Type-Defect Priority-Medium

  Sure thing. We'll do this for the next release.

  Status: Started

  Labels: Type-Defect Priority-Medium
• Nov 24, 2009

  issue 50 (template_modifiers.h unused parameters) reported by pepone.onrez   -   I get this warning from the unused paramenters in MightModify from /opt/ctemplate/include/ctemplate/template.h:48, from Hello.cpp:8: /opt/ctemplate/include/ctemplate/template_modifiers.h:116: warning: unused parameter ‘per_expand_data’ /opt/ctemplate/include/ctemplate/template_modifiers.h:116: warning: unused parameter ‘arg’ virtual bool MightModify(const PerExpandData* per_expand_data, const std::string& arg) const { return true; } It will be better to get rid of the name of the unused parameters to avoid this warnning. virtual bool MightModify(const PerExpandData*, const std::string&) const { return true; }

  I get this warning from the unused paramenters in MightModify from /opt/ctemplate/include/ctemplate/template.h:48, from Hello.cpp:8: /opt/ctemplate/include/ctemplate/template_modifiers.h:116: warning: unused parameter ‘per_expand_data’ /opt/ctemplate/include/ctemplate/template_modifiers.h:116: warning: unused parameter ‘arg’ virtual bool MightModify(const PerExpandData* per_expand_data, const std::string& arg) const { return true; } It will be better to get rid of the name of the unused parameters to avoid this warnning. virtual bool MightModify(const PerExpandData*, const std::string&) const { return true; }
• Nov 24, 2009

  issue 49 (Use full qualified names in headers) commented on by pepone.onrez   -   Yeah it would be perfect

  Yeah it would be perfect
• Nov 24, 2009

  issue 48 (Compile ctemplate with MinGW GCC 4.4.0) Labels changed by csilvers   -   Wow, that's impressive work! I don't know what libsupc++, and how much of what you did was needed for shared libgcc (is shared libgcc normal in msys-land?) vs how much is just ctemplate not supporting mingw, but there's definitely some of the latter, which I'll try to fix up in the next release. It shouldn't be that hard. It's not clear to me which script test was breaking for you -- the project has several. What's the actual error/failure message that you got? If it's in make_tpl_varnames_h_unittest, then the data lives in /tmp/make_tpl_varnames_h_unittest_sh_dir.

  Labels: Type-Enhancement Priority-Medium

  Wow, that's impressive work! I don't know what libsupc++, and how much of what you did was needed for shared libgcc (is shared libgcc normal in msys-land?) vs how much is just ctemplate not supporting mingw, but there's definitely some of the latter, which I'll try to fix up in the next release. It shouldn't be that hard. It's not clear to me which script test was breaking for you -- the project has several. What's the actual error/failure message that you got? If it's in make_tpl_varnames_h_unittest, then the data lives in /tmp/make_tpl_varnames_h_unittest_sh_dir.

  Labels: Type-Enhancement Priority-Medium
• Nov 24, 2009

  issue 49 (Use full qualified names in headers) changed by csilvers   -   This is a good point. I'll actually make it static const ::ctemplate::StaticTemplateString kM_MenuItem = ... (note the leading ::). Would that work for you? I'll make that part of the next release.

  Status: Started

  Labels: Type-Defect Priority-Medium

  This is a good point. I'll actually make it static const ::ctemplate::StaticTemplateString kM_MenuItem = ... (note the leading ::). Would that work for you? I'll make that part of the next release.

  Status: Started

  Labels: Type-Defect Priority-Medium
• Nov 24, 2009

  issue 49 (Use full qualified names in headers) reported by pepone.onrez   -   ctemlate 0.96 generates #include <ctemplate/template_string.h> static const StaticTemplateString kM_MenuItem = STS_INIT_WITH_HASH(kM_MenuItem, "MenuItem", 12751148691163768839LLU); It will be better if the is generated as static const ctemplate::StaticTemplateString kM_MenuItem = STS_INIT_WITH_HASH(kM_MenuItem, "MenuItem", 12751148691163768839LLU); In that way i will be not forced to put "using namespace ctemplate;" before include the generated file

  ctemlate 0.96 generates #include <ctemplate/template_string.h> static const StaticTemplateString kM_MenuItem = STS_INIT_WITH_HASH(kM_MenuItem, "MenuItem", 12751148691163768839LLU); It will be better if the is generated as static const ctemplate::StaticTemplateString kM_MenuItem = STS_INIT_WITH_HASH(kM_MenuItem, "MenuItem", 12751148691163768839LLU); In that way i will be not forced to put "using namespace ctemplate;" before include the generated file
• Nov 19, 2009

  issue 48 (Compile ctemplate with MinGW GCC 4.4.0) reported by jonathan.brandmeyer   -   This is more about what I did to make it work rather than a defect itself. The goal was to compile against shared libgcc and libstdc++.dll with GCC 4.4.0 (MinGW stock). I would appreciate some assistance in figuring out why the SCRIPTS test fails. The two outputs look the same on-screen, but I cannot find where these files are actually layed out on-disk for comparison. configure was run within MSYS with default options, and the following environment variables set: CXXLD=gcc LDFLAGS="-shared-libgcc -Wl,--enable-auto-import -Wl,--enable-auto-image-base -Wl,--export-all-symbols" LIBS="-lstdc++_s -lsupc++" Manually edit the resulting Makefile: set line 311 to CXXLD=gcc set line 427 to PTHREAD_LIBS=-mthreads Near line 100, add libctemplate_la-port.lo to am_libctemplate_la_OBJECTS Repeat for am_objects_2 am_objects_3 and am_objects_4. Near line 1215, copy the definition of libctemplate_la-template.lo to provide a rule for libctemplate_la-port.lo depending on src/windows/port.cc Manually edit src/config.h: #undef HAVE_RWLOCK #undef HAVE_PTHREAD #define PRIdS "Id" #define PRIuS "Iu" #define PRIxS "Ix" #ifndef GOOGLE_CTEMPLATE_WINDOWS_CONFIG_H #define GOOGLE_CTEMPLATE_WINDOWS_CONFIG_H #include "windows/port.h" #endif Manually edit src/windows/port.h (see attached) Compile the project with `make -j2`. Observe repeated warnings about src/ctemplate/template_string.h:165 dereferencing pointer <anonymous> does break strict-aliasing rules Observe that libtool in its great idiocy on windows will refuse to link DLL's against libsupc++.a. Therefore, manually link them as follows: $ cd .libs $ gcc -shared -shared-libgcc -mthreads -o ctemplate.dll -Wl,--out-implib,libctemplate.a libctemplate_la*.o -lstdc++_s -lsupc++ -Wl,--enable-auto-image-base -Wl,--enable-auto-import -Wl,--export-all-symbols $ # Repeat for the other 3 dll configurations $ cp *.dll ../ && cd ../ Compile and run the test suite. Remove the check_SCRIPTS task from check-am, near line 2135. This test fails (due to line endings?) and inhibits further testing $ PATH=/c/Python26:$PATH make check =================== All 18 tests passed =================== The resulting ctemplate.dll depends on libstdc++-6.dll libgcc_s_dw2-1.dll, mingwm10.dll, and msvcrt.dll. I have attached all four DLLs. The non-debug builds have been stripped.

  This is more about what I did to make it work rather than a defect itself. The goal was to compile against shared libgcc and libstdc++.dll with GCC 4.4.0 (MinGW stock). I would appreciate some assistance in figuring out why the SCRIPTS test fails. The two outputs look the same on-screen, but I cannot find where these files are actually layed out on-disk for comparison. configure was run within MSYS with default options, and the following environment variables set: CXXLD=gcc LDFLAGS="-shared-libgcc -Wl,--enable-auto-import -Wl,--enable-auto-image-base -Wl,--export-all-symbols" LIBS="-lstdc++_s -lsupc++" Manually edit the resulting Makefile: set line 311 to CXXLD=gcc set line 427 to PTHREAD_LIBS=-mthreads Near line 100, add libctemplate_la-port.lo to am_libctemplate_la_OBJECTS Repeat for am_objects_2 am_objects_3 and am_objects_4. Near line 1215, copy the definition of libctemplate_la-template.lo to provide a rule for libctemplate_la-port.lo depending on src/windows/port.cc Manually edit src/config.h: #undef HAVE_RWLOCK #undef HAVE_PTHREAD #define PRIdS "Id" #define PRIuS "Iu" #define PRIxS "Ix" #ifndef GOOGLE_CTEMPLATE_WINDOWS_CONFIG_H #define GOOGLE_CTEMPLATE_WINDOWS_CONFIG_H #include "windows/port.h" #endif Manually edit src/windows/port.h (see attached) Compile the project with `make -j2`. Observe repeated warnings about src/ctemplate/template_string.h:165 dereferencing pointer <anonymous> does break strict-aliasing rules Observe that libtool in its great idiocy on windows will refuse to link DLL's against libsupc++.a. Therefore, manually link them as follows: $ cd .libs $ gcc -shared -shared-libgcc -mthreads -o ctemplate.dll -Wl,--out-implib,libctemplate.a libctemplate_la*.o -lstdc++_s -lsupc++ -Wl,--enable-auto-image-base -Wl,--enable-auto-import -Wl,--export-all-symbols $ # Repeat for the other 3 dll configurations $ cp *.dll ../ && cd ../ Compile and run the test suite. Remove the check_SCRIPTS task from check-am, near line 2135. This test fails (due to line endings?) and inhibits further testing $ PATH=/c/Python26:$PATH make check =================== All 18 tests passed =================== The resulting ctemplate.dll depends on libstdc++-6.dll libgcc_s_dw2-1.dll, mingwm10.dll, and msvcrt.dll. I have attached all four DLLs. The non-debug builds have been stripped.

Earlier this year

• Nov 12, 2009

  issue 47 (Cookie support) Status changed by csilvers   -   Hmm, I don't know what "cookie support" is. But there's a mailing list, google-ctemplate@googlegroups.com, as mentioned on the project home page.

  Status: Invalid

  Hmm, I don't know what "cookie support" is. But there's a mailing list, google-ctemplate@googlegroups.com, as mentioned on the project home page.

  Status: Invalid
• Nov 11, 2009

  issue 47 (Cookie support) reported by postmas...@postales-apasionadas.com   -   Is there cookie support for this? Is there a mailing list or forum for google-ctemplate? Thank you

  Is there cookie support for this? Is there a mailing list or forum for google-ctemplate? Thank you
• Oct 20, 2009

  issue 45 (Fails to build in ) commented on by gianni.rossi   -   I've tested it and can confirm: it has been fixed. Thank you.

  I've tested it and can confirm: it has been fixed. Thank you.
• Oct 20, 2009

  issue 46 (contrib/tpl-mode fix for multiline comments) Status changed by csilvers   -   I took something similar to the original proposal for ctemplate 0.96, just released. I agree with Tony's comment it doesn't deal properly with } inside comments, but I think that's pretty rare, so I'm not worrying about it too much. I'm happy to accept better regexp's in the future, though. :-)

  Status: Fixed

  I took something similar to the original proposal for ctemplate 0.96, just released. I agree with Tony's comment it doesn't deal properly with } inside comments, but I think that's pretty rare, so I'm not worrying about it too much. I'm happy to accept better regexp's in the future, though. :-)

  Status: Fixed
• Oct 20, 2009

  issue 45 (Fails to build in ) Status changed by csilvers   -   This should be fixed in ctemplate 0.96, just released. If not, please feel free to reopen the bug.

  Status: Fixed

  This should be fixed in ctemplate 0.96, just released. If not, please feel free to reopen the bug.

  Status: Fixed
• Oct 20, 2009

  issue 44 (ctemplate fails with "segmentation fault" on ARM) Status changed by csilvers   -   This should be fixed in ctemplate 0.96, just released.

  Status: Fixed

  This should be fixed in ctemplate 0.96, just released.

  Status: Fixed
• Oct 20, 2009

  issue 39 (cl : Command line warning D9035 : option 'Wp64' has been dep...) Status changed by csilvers   -   This should be fixed in ctemplate 0.96, just released.

  Status: Fixed

  This should be fixed in ctemplate 0.96, just released.

  Status: Fixed
• Oct 20, 2009

  r45 (Tag for ctemplate 0.96) committed by csilvers   -   Tag for ctemplate 0.96

  Tag for ctemplate 0.96
• Oct 20, 2009

  r44 (Mon Oct 19 11:42:57 2009 Google Inc. <opensource@google.com...) committed by csilvers   -   Mon Oct 19 11:42:57 2009 Google Inc. <opensource@google.com> * ctemplate: version 0.96 release * Support multiple template root directories (williasr) * Remove TemplateContext from TemplateToString (jad) * Remove programmatic auto-escape code (jad) * Speedup: use linker to detect immutable TemplateStrings (csilvers) * Implement ShowTemplateGlobalSection (williasr) * Change SetIntValue to accept longs (omoikane) * Allow TemplateDictionary c'tor to take a TemplateString (csilvers) * Make Mutex safer to run during global destructors (csilvers) * BUILD: don't set TMPDIR when building; ar reads it (csilvers) * BUILD: fix compiling of C (as opposed to C++) test file (csilvers) * BUILD: remove bash-specific 'test x == y' from configure.ac (csilvers) * BUGFIX: use AllocAligned when allocating non-char objects (csilvers) * PORTING: remove obsolete MSVC Detect64BitPortabilityProblems (csilvers) * Updated from autoconf 2.61 to 2.62

  Mon Oct 19 11:42:57 2009 Google Inc. <opensource@google.com> * ctemplate: version 0.96 release * Support multiple template root directories (williasr) * Remove TemplateContext from TemplateToString (jad) * Remove programmatic auto-escape code (jad) * Speedup: use linker to detect immutable TemplateStrings (csilvers) * Implement ShowTemplateGlobalSection (williasr) * Change SetIntValue to accept longs (omoikane) * Allow TemplateDictionary c'tor to take a TemplateString (csilvers) * Make Mutex safer to run during global destructors (csilvers) * BUILD: don't set TMPDIR when building; ar reads it (csilvers) * BUILD: fix compiling of C (as opposed to C++) test file (csilvers) * BUILD: remove bash-specific 'test x == y' from configure.ac (csilvers) * BUGFIX: use AllocAligned when allocating non-char objects (csilvers) * PORTING: remove obsolete MSVC Detect64BitPortabilityProblems (csilvers) * Updated from autoconf 2.61 to 2.62
• Oct 20, 2009

  ctemplate-0.96.tar.gz (Tarball for ctemplate 0.96) file uploaded by csilvers   -  

  Labels: Type-Source OpSys-All Featured

  Labels: Type-Source OpSys-All Featured
• Oct 20, 2009

  ctemplate-0.96.zip (Zip file for ctemplate 0.96 (includes .sln and .vcproj files...) file uploaded by csilvers   -  

  Labels: Type-Source OpSys-Windows Featured

  Labels: Type-Source OpSys-Windows Featured
• Oct 20, 2009

  libctemplate0_0.96-1_amd64.deb (Deb for ctemplate 0.96 (64 bit)) file uploaded by csilvers   -  

  Labels: Type-Package OpSys-Linux

  Labels: Type-Package OpSys-Linux
• Oct 20, 2009

  libctemplate-dev_0.96-1_amd64.deb (Development deb for ctemplate 0.96 (64 bit)) file uploaded by csilvers   -  

  Labels: Type-Package OpSys-Linux

  Labels: Type-Package OpSys-Linux
• Oct 20, 2009

  libctemplate0_0.96-1_i386.deb (Deb for ctemplate 0.96) file uploaded by csilvers   -  

  Labels: Type-Package OpSys-Linux

  Labels: Type-Package OpSys-Linux
• Oct 20, 2009

  libctemplate-dev_0.96-1_i386.deb (Development deb for ctemplate 0.96) file uploaded by csilvers   -  

  Labels: Type-Package OpSys-Linux

  Labels: Type-Package OpSys-Linux
• Oct 20, 2009

  ctemplate-devel-0.96-1.i386.rpm (Development RPM for ctemplate 0.96) file uploaded by csilvers   -  

  Labels: Type-Package OpSys-Linux

  Labels: Type-Package OpSys-Linux
• Oct 20, 2009

  ctemplate-0.96-1.i386.rpm (RPM for ctemplate 0.96) file uploaded by csilvers   -  

  Labels: Type-Package OpSys-Linux

  Labels: Type-Package OpSys-Linux
• Oct 20, 2009

  ctemplate-devel-0.96-1.amd64.rpm (Development RPM for ctemplate 0.96 (64 bit)) file uploaded by csilvers   -  

  Labels: Type-Package OpSys-Linux

  Labels: Type-Package OpSys-Linux
• Oct 20, 2009

  ctemplate-0.96-1.amd64.rpm (RPM for ctemplate 0.96 (64 bit)) file uploaded by csilvers   -  

  Labels: Type-Package OpSys-Linux

  Labels: Type-Package OpSys-Linux
• Oct 19, 2009

  issue 45 (Fails to build in ) commented on by gianni.rossi   -   Which '=='? Could you attach the file with this fix so I could test it?

  Which '=='? Could you attach the file with this fix so I could test it?
• Oct 13, 2009

  issue 46 (contrib/tpl-mode fix for multiline comments) commented on by john.douglas.pritchard   -   Hi Tony, I haven't. I'm getting by with "\\({{![^}]+?}}\\)". John

  Hi Tony, I haven't. I'm getting by with "\\({{![^}]+?}}\\)". John
• Oct 13, 2009

  issue 46 (contrib/tpl-mode fix for multiline comments) commented on by to...@google.com   -   Hi John, Thanks for the patch! I'm assuming you mean "\\({{![^}]*?}}\\)" instead of "\\({{![^}]?}}\\)". Right? In that case, it looks like this would prevent comments like: {{! I'm a closing brace "}". }} But allow comments like: {{! Line 1 Line 2 }} That seems okay, but I wonder if we could allow line breaks without preventing closing braces in comments. In some regex implementations, [^] matches any character including line breaks (i.e. "\\({{![^]*?}}\\)"), but I haven't tested that in an emacs mode. Have you tried that? Tony

  Hi John, Thanks for the patch! I'm assuming you mean "\\({{![^}]*?}}\\)" instead of "\\({{![^}]?}}\\)". Right? In that case, it looks like this would prevent comments like: {{! I'm a closing brace "}". }} But allow comments like: {{! Line 1 Line 2 }} That seems okay, but I wonder if we could allow line breaks without preventing closing braces in comments. In some regex implementations, [^] matches any character including line breaks (i.e. "\\({{![^]*?}}\\)"), but I haven't tested that in an emacs mode. Have you tried that? Tony
• Oct 13, 2009

  issue 14 (Build system doesn't work with automake1.10) Status changed by csilvers   -   I looked into it, and there's no way (that I see) to use the -xc for compiling but not for linking. So I went with my other solution, which is to copy statemachine.cc to statemachine.c. That seems to work -- it invokes gcc now, not g++, so I can get rid of -xc -- so I'll put it in the next release of ctemplate.

  Status: Started

  I looked into it, and there's no way (that I see) to use the -xc for compiling but not for linking. So I went with my other solution, which is to copy statemachine.cc to statemachine.c. That seems to work -- it invokes gcc now, not g++, so I can get rid of -xc -- so I'll put it in the next release of ctemplate.

  Status: Started
• Oct 12, 2009

  issue 46 (contrib/tpl-mode fix for multiline comments) changed by csilvers   -   Thanks for the suggestion. I'll track down tonyg and pass this along.

  Status: Started

  Labels: Type-Patch Priority-Medium

  Thanks for the suggestion. I'll track down tonyg and pass this along.

  Status: Started

  Labels: Type-Patch Priority-Medium
• Oct 12, 2009

  issue 45 (Fails to build in ) Status changed by csilvers   -   OK, I'm going to assume it's that == is a bash-ism, then. I've fixed this for the next release. Let's revisit this bug then and see if it's fixed for you.

  Status: Started

  OK, I'm going to assume it's that == is a bash-ism, then. I've fixed this for the next release. Let's revisit this bug then and see if it's fixed for you.

  Status: Started
• Oct 10, 2009

  issue 46 (contrib/tpl-mode fix for multiline comments) reported by john.douglas.pritchard   -   In tpl-mode.el http://code.google.com/p/google-ctemplate/source/browse/trunk/contrib/tpl-mode.el There's a TODO for multiline comments, ;; TODO(tonyg) Figure out a way to support multiline comments. (defconst tpl-mode-comment "\\({{!.*?}}\\)") The repaired line could read (defconst tpl-mode-comment "\\({{![^}]?}}\\)") This is known to work. See http://code.google.com/p/hapax2/source/browse/support/emacs/tpl-mode.el

  In tpl-mode.el http://code.google.com/p/google-ctemplate/source/browse/trunk/contrib/tpl-mode.el There's a TODO for multiline comments, ;; TODO(tonyg) Figure out a way to support multiline comments. (defconst tpl-mode-comment "\\({{!.*?}}\\)") The repaired line could read (defconst tpl-mode-comment "\\({{![^}]?}}\\)") This is known to work. See http://code.google.com/p/hapax2/source/browse/support/emacs/tpl-mode.el
• Oct 06, 2009

  issue 45 (Fails to build in ) commented on by gianni.rossi   -   'bash configure' works fine!

  'bash configure' works fine!
• Oct 02, 2009

  issue 14 (Build system doesn't work with automake1.10) commented on by csilvers   -   I looked into this a big more, and the problem isn't the lack of extern "C", the problem is that statemachine.cc needs to be compiled as a C file, despite its extension. gcc is auto-detecting it as a c++ file (it's written to compile both ways), and hence you're seeing these errors. The right fix is to use -xc at compile time but not at link time. Or maybe it would work just to copy statemachine.cc to statemachine.c and to change the Makefile.am to change: --- statemachine_test_SOURCES = src/tests/statemachine_test.c \ src/htmlparser/statemachine.cc --- to --- statemachine_test_SOURCES = src/tests/statemachine_test.c \ src/htmlparser/statemachine.c --- (And also take out the -xc.) Do you want to try that and see if it fixes things for you?

  I looked into this a big more, and the problem isn't the lack of extern "C", the problem is that statemachine.cc needs to be compiled as a C file, despite its extension. gcc is auto-detecting it as a c++ file (it's written to compile both ways), and hence you're seeing these errors. The right fix is to use -xc at compile time but not at link time. Or maybe it would work just to copy statemachine.cc to statemachine.c and to change the Makefile.am to change: --- statemachine_test_SOURCES = src/tests/statemachine_test.c \ src/htmlparser/statemachine.cc --- to --- statemachine_test_SOURCES = src/tests/statemachine_test.c \ src/htmlparser/statemachine.c --- (And also take out the -xc.) Do you want to try that and see if it fixes things for you?
• Oct 02, 2009

  issue 45 (Fails to build in ) commented on by csilvers   -   OK, I'm at a loss. Everything seems to be working properly, to me. My only guess is I have a bash-ism in there somewhere. What happens when you run bash configure instead of just ./configure?

  OK, I'm at a loss. Everything seems to be working properly, to me. My only guess is I have a bash-ism in there somewhere. What happens when you run bash configure instead of just ./configure?
• Oct 02, 2009

  issue 14 (Build system doesn't work with automake1.10) commented on by csilvers   -   Ah, that seems likely. The test is working already! I wonder why we don't get any bug reports like this with automake 1.10 though. In any case, I'll look into this and see if I can fix it for the next release. Probably because automake 1.10 compiles it as a c++ file.

  Ah, that seems likely. The test is working already! I wonder why we don't get any bug reports like this with automake 1.10 though. In any case, I'll look into this and see if I can fix it for the next release. Probably because automake 1.10 compiles it as a c++ file.
• Oct 01, 2009

  issue 14 (Build system doesn't work with automake1.10) commented on by m...@ucc.asn.au   -   Removing the -cx I get problems with linking statemachine_test (see make output below). Since statemachine_test.c is built with gcc (which seems right, its extension is .c) then the .o has statemachine_encode_char etc as non-mangled symbols. If statemachine's meant to be callable from C should statemachine.h be wrapped in extern "C" perhaps? I'm not sure the intent of it all though. ghost3:~/ctemplate-0.95 make make all-am make[1]: Entering directory `/home/matt/ctemplate-0.95' gcc -DHAVE_CONFIG_H -I. -I./src -I./src -ggdb -Wall -D_FORTIFY_SOURCE=1 -pipe -O2 -MT statemachine_test.o -MD -MP -MF .deps/statemachine_test.Tpo -c -o statemachine_test.o `test -f 'src/tests/statemachine_test.c' || echo './'`src/tests/statemachine_test.c mv -f .deps/statemachine_test.Tpo .deps/statemachine_test.Po /bin/sh ./libtool --tag=CXX --mode=link g++ -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -ggdb -Wall -D_FORTIFY_SOURCE=1 -pipe -O2 -o statemachine_test statemachine_test.o statemachine.o libtool: link: g++ -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -ggdb -Wall -D_FORTIFY_SOURCE=1 -pipe -O2 -o statemachine_test statemachine_test.o statemachine.o statemachine_test.o(.text+0x51): In function `test_encode_char': src/tests/statemachine_test.c:342: undefined reference to `statemachine_encode_char' statemachine_test.o(.text+0xdc):src/tests/statemachine_test.c:347: undefined reference to `statemachine_encode_char' statemachine_test.o(.text+0x1ac):src/tests/statemachine_test.c:350: undefined reference to `statemachine_encode_char' statemachine_test.o(.text+0x1e3):src/tests/statemachine_test.c:353: undefined reference to `statemachine_encode_char' statemachine_test.o(.text+0x22c):src/tests/statemachine_test.c:356: undefined reference to `statemachine_encode_char' statemachine_test.o(.text+0x288):src/tests/statemachine_test.c:359: more undefined references to `statemachine_encode_char' follow statemachine_test.o(.text+0x437): In function `test_copy': src/tests/statemachine_test.c:281: undefined reference to `statemachine_definition_new' statemachine_test.o(.text+0x449):src/tests/statemachine_test.c:282: undefined reference to `statemachine_new' statemachine_test.o(.text+0x463):src/tests/statemachine_test.c:284: undefined reference to `statemachine_definition_populate' statemachine_test.o(.text+0x4d0):src/tests/statemachine_test.c:289: undefined reference to `statemachine_duplicate' statemachine_test.o(.text+0x544):src/tests/statemachine_test.c:292: undefined reference to `statemachine_parse' ... continues for a page

  Removing the -cx I get problems with linking statemachine_test (see make output below). Since statemachine_test.c is built with gcc (which seems right, its extension is .c) then the .o has statemachine_encode_char etc as non-mangled symbols. If statemachine's meant to be callable from C should statemachine.h be wrapped in extern "C" perhaps? I'm not sure the intent of it all though. ghost3:~/ctemplate-0.95 make make all-am make[1]: Entering directory `/home/matt/ctemplate-0.95' gcc -DHAVE_CONFIG_H -I. -I./src -I./src -ggdb -Wall -D_FORTIFY_SOURCE=1 -pipe -O2 -MT statemachine_test.o -MD -MP -MF .deps/statemachine_test.Tpo -c -o statemachine_test.o `test -f 'src/tests/statemachine_test.c' || echo './'`src/tests/statemachine_test.c mv -f .deps/statemachine_test.Tpo .deps/statemachine_test.Po /bin/sh ./libtool --tag=CXX --mode=link g++ -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -ggdb -Wall -D_FORTIFY_SOURCE=1 -pipe -O2 -o statemachine_test statemachine_test.o statemachine.o libtool: link: g++ -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -ggdb -Wall -D_FORTIFY_SOURCE=1 -pipe -O2 -o statemachine_test statemachine_test.o statemachine.o statemachine_test.o(.text+0x51): In function `test_encode_char': src/tests/statemachine_test.c:342: undefined reference to `statemachine_encode_char' statemachine_test.o(.text+0xdc):src/tests/statemachine_test.c:347: undefined reference to `statemachine_encode_char' statemachine_test.o(.text+0x1ac):src/tests/statemachine_test.c:350: undefined reference to `statemachine_encode_char' statemachine_test.o(.text+0x1e3):src/tests/statemachine_test.c:353: undefined reference to `statemachine_encode_char' statemachine_test.o(.text+0x22c):src/tests/statemachine_test.c:356: undefined reference to `statemachine_encode_char' statemachine_test.o(.text+0x288):src/tests/statemachine_test.c:359: more undefined references to `statemachine_encode_char' follow statemachine_test.o(.text+0x437): In function `test_copy': src/tests/statemachine_test.c:281: undefined reference to `statemachine_definition_new' statemachine_test.o(.text+0x449):src/tests/statemachine_test.c:282: undefined reference to `statemachine_new' statemachine_test.o(.text+0x463):src/tests/statemachine_test.c:284: undefined reference to `statemachine_definition_populate' statemachine_test.o(.text+0x4d0):src/tests/statemachine_test.c:289: undefined reference to `statemachine_duplicate' statemachine_test.o(.text+0x544):src/tests/statemachine_test.c:292: undefined reference to `statemachine_parse' ... continues for a page
• Oct 01, 2009

  issue 45 (Fails to build in ) commented on by gianni.rossi   -   tar czvf config.tgz config* ;-)

  tar czvf config.tgz config* ;-)
• Oct 01, 2009

  issue 45 (Fails to build in ) commented on by csilvers   -   Thanks. I don't see any smoking guns in these files, unfortunately. Can you also attach your config.status file? Might as well throw in your configure script for good measure.

  Thanks. I don't see any smoking guns in these files, unfortunately. Can you also attach your config.status file? Might as well throw in your configure script for good measure.
• Oct 01, 2009

  issue 14 (Build system doesn't work with automake1.10) Status changed by csilvers   -   Thanks for all the data. It does look like the -xc is the problem. When I run the link line manually that automake 1.11 generates (with -xc), I get the same error you see: g++ -xc -O0 -ggdb -Wall -o statemachine_test statemachine_test.o statemachine_test-statemachine.o When I take out the -xc, it works correctly. OK, it looks like the problem is in my Makefile.am script. I add -xc explicitly when compiling statemachine.c, just as an extra test there's no c++ code accidentally in there. I do this via CXXFLAGS, which I understand only applies at compile time. However, in automake 1.10 and later, it seems to apply (sometimes?) at link time as well. I'll have to look into the right fix. For now, you can take the '-cx' lines out of Makefile.am, and rerun automake. That should fix things -- let me know if it doesn't.

  Status: Accepted

  Thanks for all the data. It does look like the -xc is the problem. When I run the link line manually that automake 1.11 generates (with -xc), I get the same error you see: g++ -xc -O0 -ggdb -Wall -o statemachine_test statemachine_test.o statemachine_test-statemachine.o When I take out the -xc, it works correctly. OK, it looks like the problem is in my Makefile.am script. I add -xc explicitly when compiling statemachine.c, just as an extra test there's no c++ code accidentally in there. I do this via CXXFLAGS, which I understand only applies at compile time. However, in automake 1.10 and later, it seems to apply (sometimes?) at link time as well. I'll have to look into the right fix. For now, you can take the '-cx' lines out of Makefile.am, and rerun automake. That should fix things -- let me know if it doesn't.

  Status: Accepted
• Sep 30, 2009

  issue 14 (Build system doesn't work with automake1.10) commented on by m...@ucc.asn.au   -   I'm seeing the same issue here with automake 1.11 I've attached libtool, ltmain.sh, Makefile, and the make log. Let me know if you need anything else. It seems to be something to do with the -xc, but removing that it won't build either (it might be trying to link without C++ name-mangling?).

  I'm seeing the same issue here with automake 1.11 I've attached libtool, ltmain.sh, Makefile, and the make log. Let me know if you need anything else. It seems to be something to do with the -xc, but removing that it won't build either (it might be trying to link without C++ name-mangling?).
• Sep 30, 2009

  issue 45 (Fails to build in ) commented on by gianni.rossi   -   Yes, my configure has that, verbatim, and I found something very similar in configure.ac. Yes, your right, I did not copy it properly, the correct is: typedef TemplateId; I'm attaching all the files that were generated by the configure script. I extracted the tar.gz file in a new location, ran configure and tar'ed all the files listed at the end of the script that were created; e.g. config.status creating Makefile

  Yes, my configure has that, verbatim, and I found something very similar in configure.ac. Yes, your right, I did not copy it properly, the correct is: typedef TemplateId; I'm attaching all the files that were generated by the configure script. I extracted the tar.gz file in a new location, ran configure and tar'ed all the files listed at the end of the script that were created; e.g. config.status creating Makefile
• Sep 29, 2009

  issue 45 (Fails to build in ) commented on by csilvers   -   OK, something really weird is going on here. Your config.log says: ac_cv_uint64='' But the configure script says: --- if test "$ac_cv_type_u_int64_t" == "yes"; then ac_cv_uint64=u_int64_t elif test "$ac_cv_type_uint64_t" == "yes"; then ac_cv_uint64=uint64_t elif test "$ac_cv_type___int64" == "yes"; then ac_cv_uint64=unsigned __int64 else ac_cv_uint64=unsigned long long # best we can do fi --- I don't see any way ac_cv_uint64 could be assigned to ''. Does your configure script also have that code snippet above? Actually, I'm very suspicious of this: --- line in ./src/ctemplate/template_string.h: typedef TemplateId; fails. --- Is that verbatim what you had in the file? I would have expected two spaces between typedef and TemplateId. Maybe you can attach this entire file?

  OK, something really weird is going on here. Your config.log says: ac_cv_uint64='' But the configure script says: --- if test "$ac_cv_type_u_int64_t" == "yes"; then ac_cv_uint64=u_int64_t elif test "$ac_cv_type_uint64_t" == "yes"; then ac_cv_uint64=uint64_t elif test "$ac_cv_type___int64" == "yes"; then ac_cv_uint64=unsigned __int64 else ac_cv_uint64=unsigned long long # best we can do fi --- I don't see any way ac_cv_uint64 could be assigned to ''. Does your configure script also have that code snippet above? Actually, I'm very suspicious of this: --- line in ./src/ctemplate/template_string.h: typedef TemplateId; fails. --- Is that verbatim what you had in the file? I would have expected two spaces between typedef and TemplateId. Maybe you can attach this entire file?
• Sep 29, 2009

  issue 45 (Fails to build in ) commented on by gianni.rossi   -   Looking back into my bash_history to confirm, I ran configure like this: CPPFLAGS="-Os -march=native -fomit-frame-pointer" ./configure which runs fine on my Gentoo box. If it helps, my Gentoo uses gcc 4.4.1 and my FreeBSD uses 4.2.1, also: [root@marconi /etc]# uname -a FreeBSD marconi.domain 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

  Looking back into my bash_history to confirm, I ran configure like this: CPPFLAGS="-Os -march=native -fomit-frame-pointer" ./configure which runs fine on my Gentoo box. If it helps, my Gentoo uses gcc 4.4.1 and my FreeBSD uses 4.2.1, also: [root@marconi /etc]# uname -a FreeBSD marconi.domain 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386