Hi,
found a couple of things related to doxygen that I think are incorrect.
Looking ahead to say, the project directory tree looks like this:
project/
bin/
debug/
release/
build/
doxygen/
doc/
In the build/ directory is a project file project.cbp. In the doxygen/ directory is a file doxyfile. debug/ and release/ is the directory in which the executable files are placed. And directory doc/ where doxygen generates html.
Firstly, perform the menu item DoxyBlocks→Doxywizard...
When the project has just opened and when menu item performed in the tab DoxyBlocks displays the following output:
Running doxywizard...
Process 16240 (C:\Program Files\doxygen\bin\doxywizard.exe C:\Users\Aleksandr\Code\C++\project\build\doxygen\doxyfile) launched.
And in the opened dialog one can see that the file doxyfile was successfully readed.
But after has been run one of the targets (debug or release) the output changed to the following:
Running doxywizard...
Process 22804 (C:\Program Files\doxygen\bin\doxywizard.exe C:\Users\Aleksandr\Code\C++\project\bin\debug\doxygen\doxyfile) launched.
or
Running doxywizard...
Process 17736 (C:\Program Files\doxygen\bin\doxywizard.exe C:\Users\Aleksandr\Code\C++\project\bin\release\doxygen\doxyfile) launched.
respectively. It is obvious that the file is not readed. But, perform the menu item DoxyBlocks→Extract documentation is still correct.
Secondly... well, it probably does not apply to the C::B, but to the plugin DoxyBlocks. I don't know.
So, as you can see the directory tree before, doxygen is configured to put everything in the directory doc/. Nevertheless, after extracting documentation path in a message about the location of the generated document is invalid:
----------------------------------------------------------------------------------------------------
Extracting documentation for project.
DoxyBlocks is working, please wait a few moments...
Found existing doxyfile...
Success.
Your documents are in: C:\Users\Aleksandr\Code\C++\project\build\doxygen\
Done.
And perform the menu item DoxyBlocks→Run HTML fails:
Index.html not found at C:\Users\Aleksandr\Code\C++\project\build\doxygen\html/index.html.
Thats it.
Yeah, it looks like CC don't set the PATH environment to run the gcc or g++ command.
The related code:
void NativeParser::AddGCCCompilerDirs(const wxString& masterPath, const wxString& compilerCpp, ParserBase* parser)
{
wxFileName fn(wxEmptyString, compilerCpp);
wxString masterPathNoMacros(masterPath);
Manager::Get()->GetMacrosManager()->ReplaceMacros(masterPathNoMacros);
fn.SetPath(masterPathNoMacros);
fn.AppendDir(_T("bin"));
const wxArrayString& gccDirs = GetGCCCompilerDirs(fn.GetFullPath());
TRACE(_T("NativeParser::AddGCCCompilerDirs(): Adding %lu cached gcc dirs to parser..."), static_cast<unsigned long>(gccDirs.GetCount()));
for (size_t i=0; i<gccDirs.GetCount(); ++i)
{
parser->AddIncludeDir(gccDirs[i]);
TRACE(_T("NativeParser::AddGCCCompilerDirs(): Adding cached compiler dir to parser: ") + gccDirs[i]);
}
}
Run the command to fetch the GCC's include paths.
// These dirs are the built-in search dirs of the compiler itself (GCC).
// Such as when you install your MinGW GCC in E:/code/MinGW/bin
// The buildin search dir may contains: E:/code/MinGW/include
const wxArrayString& NativeParser::GetGCCCompilerDirs(const wxString &cpp_compiler)
{
// keep the gcc compiler path's once if found across C::B session
// makes opening workspaces a *lot* faster by avoiding endless calls to the compiler
static std::map<wxString, wxArrayString> dirs;
if (!dirs[cpp_compiler].IsEmpty())
return dirs[cpp_compiler];
// wxExecute can be a long action and C::B might have been shutdown in the meantime...
// This is here, to protect at re-entry:
if (Manager::IsAppShuttingDown())
return dirs[cpp_compiler];
TRACE(_T("NativeParser::GetGCCCompilerDirs(): Enter"));
// for starters , only do this for gnu compiler
//CCLogger::Get()->DebugLog(_T("CompilerID ") + CompilerID);
//
// Windows: mingw32-g++ -v -E -x c++ nul
// Linux : g++ -v -E -x c++ /dev/null
// do the trick only for c++, not needed then for C (since this is a subset of C++)
// let's construct the command
// use a null file handler
// both works fine in Windows and Linux
wxString Command(cpp_compiler + _T(" -v -E -x c++ /dev/null"));
if (platform::windows)
Command = cpp_compiler + _T(" -v -E -x c++ nul"); // on Windows, its different
static bool flag = false;
if (flag)
return dirs[cpp_compiler];
// action time (everything shows up on the error stream
wxArrayString Output, Errors;
flag = true;
if ( wxExecute(Command, Output, Errors, wxEXEC_SYNC | wxEXEC_NODISABLE) == -1 )
{
TRACE(_T("NativeParser::GetGCCCompilerDirs(): GetGCCCompilerDirs::wxExecute failed!"));
flag = false;
return dirs[cpp_compiler];
}
flag = false;
// wxExecute can be a long action and C::B might have been shutdown in the meantime...
// This is here, to protect a long run:
if ( Manager::IsAppShuttingDown() )
return dirs[cpp_compiler];
// start from "#include <...>", and the path followed
// let's hope this does not change too quickly, otherwise we need
// to adjust our search code (for several versions ...)
bool start = false;
for (size_t idxCount = 0; idxCount < Errors.GetCount(); ++idxCount)
{
wxString path = Errors[idxCount].Trim(true).Trim(false);
if (!start)
{
if (!path.StartsWith(_T("#include <...>")))
continue;
path = Errors[++idxCount].Trim(true).Trim(false);
start = true;
}
wxFileName fname(path, wxEmptyString);
fname.Normalize();
fname.SetVolume(fname.GetVolume().MakeUpper());
if (!fname.DirExists())
break;
dirs[cpp_compiler].Add(fname.GetPath());
CCLogger::Get()->DebugLog(_T("NativeParser::GetGCCCompilerDirs(): Caching GCC default include dir: ") + fname.GetPath());
}
TRACE(_T("NativeParser::GetGCCCompilerDirs(): Leave"));
return dirs[cpp_compiler];
}
You can to try if downloading it from my server (https://apt.jenslody.de/downloads/cb_nightly_9916/ (https://apt.jenslody.de/downloads/cb_nightly_9916/)) works.
md5 hashes:
7639e8e7726cf6c03fe214b95915bbea CB_20140916_rev9916_win32.7z
71e005f599ee9cd2b78b2fc7eb6ffa84 mingwm10_gcc481-TDM.7z
f8c3640e7b55df11d0e0aacb36450019 wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z
crc32 hashes:
bb8a31c2 CB_20140916_rev9916_win32.7z
a7612ce4 mingwm10_gcc481-TDM.7z
ea91c474 wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z
sizes:
9200027 CB_20140916_rev9916_win32.7z
5683 mingwm10_gcc481-TDM.7z
1565385 wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z
Hi
Maybe some one can check the integrity of the sourceforge files, i doubt that is the issue. Not really sure what happened.
I've juste re-downloaded the 7z archive, and the SHA1 checksum is correct :
5483ce117a0cd4a4bcf1d8e1001e5495897315bc CB_20140916_rev9916_win32.7z
Regards
Xav'