This is likely historical, but I would like to understand why cppunit considers itself "System Software"? All the includes are indicated with <> instead of the usual "".
Curious minds want to know?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For the cpp file it is ok. #include <filename> states that include path indicate with /I option are search first, then those of the environment variable.
For the header in the /include directory, it might be a problem because that include directory may not be the one in the include paths.
I spotted that problem a few day ago (I'm working on a simple dependency analyser for my Qt TestRunner pet project).
I haven't raise the that yet. But I run into some issue when I try to think about a solution:
For example, in cppunit/extensions/HelperMacros.h, you have:
I you replace with the quoted filename:
#include "../Portability.h"
#include "AutoRegisterSuite.h"
#include "TestSuiteBuilder.h"
For AutoRegisterSuite.h and TestSuiteBuilder.h, it's ok, and actually what should be done. But I frown upon having "../" in an include filename. Given the quoted include rules "search parent files include directory", you could include something completly different if you misstype the filename, or have it working because the file would be found using some of the 'system' includes.
=> Include in the same directory will be converted to quoted notation, but I fell uneasy about doing that when including file from another directory.
How would you have thing ?
Baptiste.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been away from command line compilers for several years, so I guess I should defer to those more knowledgable.
The basic premis of include files has always been <> indicate system file includes. It just seems unusual that an "add on" library would use system file syntax.
In general I defer to previous examples. Can an example of something similer be shown where the system include file syntax was used?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The common myth is that #include <file.h> must be a system file is not true. In fact #include <file.h> is intended to be used with -Ipath options because the precompiler search system paths + "-Ipath" locations.
#include "file.h" means please search the *current* directory, AND IF, and search path is present, then find include file elsewhere. Since cppunit will never be in the current path by default, then #include <file.h> is correct usage. #include "file.h" is most appropriate for private/local interface files being included by implementation files (e.g. calc.cpp #including localdefs.h).
Way back when, X11 did not start out being a part of the system. But its header files where included as #include <X11/File.h> for instance.
Perhaps this post is a little too opininated, but I wanted to at least try and dispell the #include <file.h> is for system headers only.
In summary, I would not change anything here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is likely historical, but I would like to understand why cppunit considers itself "System Software"? All the includes are indicated with <> instead of the usual "".
Curious minds want to know?
For the cpp file it is ok. #include <filename> states that include path indicate with /I option are search first, then those of the environment variable.
For the header in the /include directory, it might be a problem because that include directory may not be the one in the include paths.
I spotted that problem a few day ago (I'm working on a simple dependency analyser for my Qt TestRunner pet project).
I haven't raise the that yet. But I run into some issue when I try to think about a solution:
For example, in cppunit/extensions/HelperMacros.h, you have:
#include <cppunit/Portability.h>
#include <cppunit/extensions/AutoRegisterSuite.h>
#include <cppunit/extensions/TestSuiteBuilder.h>
I you replace with the quoted filename:
#include "../Portability.h"
#include "AutoRegisterSuite.h"
#include "TestSuiteBuilder.h"
For AutoRegisterSuite.h and TestSuiteBuilder.h, it's ok, and actually what should be done. But I frown upon having "../" in an include filename. Given the quoted include rules "search parent files include directory", you could include something completly different if you misstype the filename, or have it working because the file would be found using some of the 'system' includes.
=> Include in the same directory will be converted to quoted notation, but I fell uneasy about doing that when including file from another directory.
How would you have thing ?
Baptiste.
>How would you have thing ?
I have been away from command line compilers for several years, so I guess I should defer to those more knowledgable.
The basic premis of include files has always been <> indicate system file includes. It just seems unusual that an "add on" library would use system file syntax.
In general I defer to previous examples. Can an example of something similer be shown where the system include file syntax was used?
Hi,
Please see my response on the cppunit-devel mailing list.
http://www.geocrawler.com/lists/3/SourceForge/6780/0/6706651/
-smr
The current convention is correct.
The common myth is that #include <file.h> must be a system file is not true. In fact #include <file.h> is intended to be used with -Ipath options because the precompiler search system paths + "-Ipath" locations.
#include "file.h" means please search the *current* directory, AND IF, and search path is present, then find include file elsewhere. Since cppunit will never be in the current path by default, then #include <file.h> is correct usage. #include "file.h" is most appropriate for private/local interface files being included by implementation files (e.g. calc.cpp #including localdefs.h).
Way back when, X11 did not start out being a part of the system. But its header files where included as #include <X11/File.h> for instance.
Perhaps this post is a little too opininated, but I wanted to at least try and dispell the #include <file.h> is for system headers only.
In summary, I would not change anything here.