Hi Mihir,

This error should not happen regardless of the SHORT_NAMES setting. 

The default is set to NO, and with it I never saw this problem myself, so can you attach an example (source file + config file in a zip) that allows me to reproduce the problem (if possible outside of eclipse)?

Also did you think it is related to this issue?

http://osdir.com/ml/text.doxygen.general/2005-09/msg00094.html

i.e. did you enable call graphs and do you get files with very long names?

It may also be relevant to know the OS and filesystem you are using...

Another possibility for such error is if you use \msc...\endmsc but have not installed mscgen

Hello,

I had this bug several times on several computers without ever understanding why. On many places on Internet I saw users reporting having "fixed" it using the SHORT_NAMES option (try this search: http://www.google.com/search?q=%22Error+opening+map+file%22+SHORT_NAMES ), but this didn't make sense to me.

But I finally ran in a strange situation which probably makes me finding the real reason of this problem :
I have two folders which contain two side by side forks of the same project. Each of them have their own configuration files, but these configuration files are absolutely identical. There was no apparent reason for that but ... when generating their respective Doxygen documentation, one of these projects had the bug and the second one not !

Thinking a lot, I tried several things, and I ended with the following : cleaning all Doxygen generated files (in the "html" folder) in the faulty project was enough for removing the bug (that is, after doing that, the new generation ran with no error).

I think now that the problem is the following :

It looks like that Doxygen has an incremental feature (that is, if you generate the same documentation several times, only changed files will be reprocessed, thus improving speed). But that way, if the previous generation was faulty, several things will not get fixed. Especially if "map" files were missing because there was an error in the previous generation. And the main reason for having "map" files missing is trying to generate graphics without having "graphViz" installed.

So probably many users proceed on the following way when using "Doxygen" for the first time :

(1) They download and install Doxygen.
(2) They try to use it for documenting some of their own projects.
(3) At a given time, they try to enable the "dot" (graphViz) for generating the project.
(4) They get a lot of errors because graphViz was not installed. Of course it wasn't, it is not included with Doxyfile! But they didn't read that yet so they return to the manual and they see that they now need to download and install graphViz (alternatively, maybe they have installed it, but not correctly).
(5) After having fixed the graphViz installation problem, they run Doxygen again on the same project.
(6) Things seem to work a little better, but now they have plenty of these "Error opening map file *.map for inclusion in the docs!". The reason is that the previous generation left a corrupted documentation in the folder, but they don't know it.
(7) They search on Internet the reason of this error and they find that many people have fixed it by setting the SHORT_NAMES option to YES.
(8) They try this, and it works. They are happy.

But what they don't know is that if the SHORT_NAMES trick works, it is not because this option was the reason of the bug, but rather that it completely changes almost all the names inside the folder, so the previous generation is not seen: a completely new set of files is generated (actually leaving the previous files orphan in the folder, which could be seen as another bug as they uselessly take space; but this is another problem).

If they had begun their first try by setting the SHORT_NAMES option to YES, they would have now to set it to NO for getting the same result.

So the correct workaround is cleaning the previous generation rather than changing the "SHORT_NAMES" option if you see this "Error opening map file *.map for inclusion in the docs!" message.

... and the bug fix could be trying to regenerate the picture if some "map" file is found missing during an incremental regeneration rather than issuing an error and ignoring this part of the project.

Gilles

Hey Dimitri.

There is new input for you in comment #3. I am thus reopening :)

I confirm the diagnosis done in comment#3 !

I just found this bug trying to generate docs for a project of mine on a new PC with Jaunty (i.e. with doxygen 1.5.8). 
The project used HAVE_DOT=YES but when I ran it the first time I didn't have DOT installed on the new machine. I got many errors about DOT. I installed it and re-run doxygen. Now a lot of errors of type:
  "Error opening map file .... for inclusion in the docs!"
appeared in the output log file (and inheritance graphs were missing).

I tried installing the SVN version but the error was still there.

I found some posts regarding SHORT_NAMES setting but then found this bug report and thanks to the  comment of "Gingko" I managed to fix the DOT issue (i.e. I removed all output files and reran doxygen; now zero errors and graphs are there!).

This suggests me that
- the status should be changed to CONFIRMED
- the problem is present also in the very latest SVN (r684) => it's not 1.5.5-specific.
- many other people have been bit by this bug => priority should be higher.

Well Francesco. Thanks for your analysis. It would help if you provide a self contained example to reproduce the bug. I.e. a tarball with all needed files or a series of commands which reproduce the bug.

Ok; here are step-by-step info to reproduce this on a Debian/Ubuntu system (I start supposing that you have the 'graphviz' package installed):

1) cd in the "examples" folder of doxygen SVN
2) doxygen diagrams.cfg
3) firefox diagrams/html/index.html: you can see the DOT-generated diagrams are there (no bugs so far)
4) rm -rf diagrams
5) sudo apt-get remove graphviz
6) doxygen diagrams.cfg: you see lots of errors about DOT not being found (ok so far); the HTML pages generated have no DOT graphs
7) sudo apt-get install graphviz
8) doxygen diagrams.cfg: you get errors like:
Error opening map file diagrams__a_8h__dep__incl.map (context (null)) for inclusion in the docs!
In the generated HTML the DOT graphs are still missing (THIS IS THE BUG)

WORKAROUND:
9) rm -rf diagrams
10) doxygen diagrams.cfg: no errors this time, graphs are in the docs.

Hope this is enough to reproduce it.

Another solution that i found is, i if change the 

FULL_PATH_NAMES        = YES ( default value )

FULL_PATH_NAMES        = NO

and leave the 

SHORT_NAMES            = NO

I don't find any Errors of following sort

Error opening map file *.map for inclusion in the docs!

Hope this helps
- Mihir

i had the same problem and it was solved after i typed "dot -c" in the windows command line.

I the meantime, doxygen does better checking if it needs to regenerate files.
Can you verify if version 1.7.4 (or better) indeed solves the reported problems, or if you still see cases where the .map files are not found?

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!

Sorry, I missed the previous message (2011-03-29).

I just checked with 1.7.4 for this bug.
The new version doesn't seem to produce the same problem, so we could consider that the bug is fixed, but in fact not in a clean manner:

Switching SHORT_NAMES from YES to NO or from NO to YES actually completely changes almost all filenames in the generation directory, so we end with a completely new set of files that are simply added to the previous ones, meaning that the number of files and the space needed are almost simply multiplied by two, but half of the files are now useless.

I think that if a change in the SHORT_NAMES option is detected, it should be better to simply decide to completely erase the Doxygen directory, forgetting the previously cached data and starting over.

Gingko

I do not want doxygen to start deleting files or complete directories. 
If I (or the user) makes a mistake, precious data may be lost.

I don't understand.

All data contained inside the Doxygen's HTML directory are automatically generated, there is not user manually generated contents.

Where do you see **any** precious data???????????????

This is like if you told me that you NEVER empty the cache of your web browser because you are afraid of loosing precious information!!!!

Gingko

Suppose a user accidentally points doxygen to the wrong directory (via a misconfigured INPUT and/or HTML_OUTPUT), then I don't want doxygen to remove all data in that directory.

If you want to clean all data, why not make a script that does so? Doxygen doesn't have to do everything. Otherwise the next question will be: if the output points to an unformatted disk, why can't doxygen format it first for me?

A user doing that would have some trouble, after that, in finding his own contents among the thousands of files commonly generated by Doxygen. :-)

Anyway, even in that case, I think that it should be quite easy to limit this risk by deleting only the files having names syntactically compatible with the Doxygen's ones.

(and no need to make any script for cleaning data, I just need to manually delete all files; this was just a matter of consistency, especially if you intend to release the resulting files on some web site like many open source developers do)

Gingko