JAYlib Wiki

Hello L. Rahyen

I'm not sure if I like the term "should either be fixed or...". First: I'm doing this on my own, second: I don't get any money for that and third: I really cannot test the gcc compiler with each version. And if you look closer: see the link GCC support above! It is mentioned there that it has only been tested with gcc3.4.4. So... Have you tried the following: see the Gcc Settings tab: remove the tick for "Includes From CDT" and paste in all the options you use to compile your files in the "Additional Options" text box (especially the -D and -I options)

Otherwise: it would be nice if you use the link at the top (in the box) "Report a Bug". The useless information would be nice too.

I'll see if I can fix that...

Thanks

 Michael 

If I use gcc-3.3 everything works fine. However, if I try to use gcc-3.4 or higher (for example, gcc-4.3), I get following bogus error: "missing implicit include:" followed by useless information (in my case - "int' / ... unsigned"). I have this error on the first line of every file.

This bug either should be fixed or at least big fat warning "anything higher than gcc-3.3 isn't supported" should be added.

Michael, thanks for the update. Yes, CppUnit is more popular . Actually, UnitTest++ produces very nice compiler like error messages: /path/file.cpp(30): error: Failure in testCaseName: Expected 3 but was 4. (30) is the line number. There is also a failure message in text mode: FAILURE: 1 out of 6 tests failed (2 failures).. Both would be easy to parse. So, I am thinking a customization similar to how I added an additional compiler would be possible. As for the compile/link problem, its not really as much of a problem in my case. The compiler is really a build process and I have a step that automatically creates and then runs the unit test program. I happen to be using Gant, but, Ant would be similar. The problem is how and when does this get run? I haven't looked at your new code, but I am thinking you have already solved this aspect.

Hello Bob, I'm not sure, I'll have to take a look on UnitTest++, but I'm not sure I'll implement some extra support... CppUnit seems to be much more widely used (at the moment). The part of CppUnit I use - on the other hand - is very small and can well be simulated. I only use the CompilerOutputter and its output is then parsed and the markers are generated. If there's a similar UnitTest++-CompilerOutputter, I think it won't be a problem, but I'm not likely to start parsing XML-files. The bigger problem is to configure the compiler in such way that an executable is created automatically from a given Unit-Testfile. At least linking will bring up some problems. I have one solution (for the gcc only) where all generated objects are linked together - external libraries may be added, but this only works, if there are no other main-functions defined... So I started to add support for embedded commands to build the executable. But that's also kind of tricky. There are a lot of problems without even starting with other test frameworks. But we'll see

Interested to hear you are working on unit test support. I will have to have a look in the future. We are currently looking at UnitTest++ instead of CppUnit - what is the outlook that the unit test support can handle different frameworks?

only available at the test-site at the moment: http://www.jaylib.org/cppchecker/test or as direct download from http://www.jaylib.org/cppchecker/cppchecker.jaylib.org-0.9.5.5-updatesite.zip

new Features:

• Doxygen view (activate with Shift+F1)
• Doxygen html in external Browser: Shift+F2
• Quick Fix - currently only working with PC-Lint + errors in included files (jumps to the referenced position) and "auto include" feature.

Also planned: quick fix add documentation (for doxygen) and rerun unit-tests, individual unit-tests (with other compilers than gcc) ... still a lot of work for the CppUnit Feature...

... finally! Holiday in Greece! But no laptop with me (unfortunately). I haven't been idle though and made some improvements to the settings-dialogs (but not finished yet). I also tried to implement a CppUnit-plug-in. The source code is already checked in and the first - very rough - try can be downloaded here. The latest test version from www.jaylib.org/cppchecker/test should be used (0.9.1.2). I used the latest cppunit sources and compiled them on Windows using cygwin. The Test-Classes should be based on CPPUNIT_NS::TestFixture and the name should end with "Test" and the test-Methods should start with "test". I recommend to try it on a simple project first, to see if it works.

example:

#include <cppunit/extensions/HelperMacros.h>
#include <Kalkulator.hpp> // self defined class

class KalkulatorTest : public CPPUNIT_NS::TestFixture
{
   public:
	   void testSqrt() { // not necessarily inline
                Kalkulator kalk;
                CPPUNIT_ASSERT(kalk.squareRoot(9) == 3);
           }
};
// in order to work there must be at least a cpp-File including the Test-header - or there's not really a header needed anyway as
// the test classes are not normally used outside their translation units (except when collecting test suites).

On errors there should occur markers on the lines, where the first assertion (per method) failed. This was quite a complicated "hack" using the internal CDT search to find the test-Methods and classes, copying the cpp-file and adding a main method (leaving out an existing main method), adding code to register all found methods in the class, compiling it using the settings from the GccParser plug-in, creating an exe using the libcppunit.dll.a library from CppUnit, executing it and interpreting the results.

Just a quick update, looks good for extending . I have an initial implementation working that did not require any base changes.

from org.eclipse.core.internal.properties.PropertyManager2.setProperty(PropertyManager2.java:154):

// enforce the limit stated by the spec
if (value != null && value.length() > 2 * 1024) {
   String message = NLS.bind(Messages.properties_valueTooLong, name.getQualifier(), name.getLocalName());
   throw new ResourceException(IResourceStatus.FAILED_WRITE_METADATA, target.getFullPath(), message, null);
}

Hm - I like magic numbers... kind of... OK - I fixed this by splitting properties, whose values are bigger than 2k automatically to indexed properties. seems to work

fixed in version 0.9.1

Hi,

setting for a project will not be saved when leaving the dialog.

I copied the seetings from my doxygen-config file into the dialog. But after checking and opening the dialog again, the setting s were gone.

Best regards Björn

Hey Bob - the test-version 0.9.0 you used still had a lot of bugs - especially in gcc handling... Hope that's all fixed now! The release 0.9.0 is the same as test-version 0.9.0.5. Well - I hope the plug-in is quite easy. As an example the doxygen plug-in is quite small. I suggest you unpack the plugin jars - at least the main plugin and doxygen - they should contain the sources and the extension-exsd. The parsers all implement the interface IParser - which is partly implement by AbstractParser. The property pages have to implement IPropertyPage.

Thanks for the information on the future plans. I upgraded to 0.9.0. A couple of things I am trying to figure out 1. CppChecker problem with GCC: missing implicit include: followed by garbage information like "mingw-vista/..." appears as an error on the first line of every file. 2. CppChecker problem with GCC: warning - previous declaration of 'function name' was here. Eclipse seems to think that they are duplicate identifiers, but they are duplicates of a file that was deleted from eclipse some time ago. Does CppChecker remember things somewhere - perhaps it is picking up old information.

It would be nice if your re-designed allow for other components to be plugged in easily - haven't had a chance to look at the source yet.

I installed a few weeks ago on Ganymede - basics seem to be working, but need to spend more time on it to provide better feedback. I am interested in PC-Lint and Doxygen support specifically and perhaps using the GCC support as a model for a different compiler.