I have several *.pl files that I'm documenting. When I run Doxygen, all the function documentation goes into the "main" class. i.e. it looks like there's one class called "main", shared by every *.pl file.
My code doesn't have any classes--it's not object-oriented Perl. It's just a couple simple scripts with subroutines. Is there any way to keep my documentation out of the "main" class? Is what I'm describing normal behavior?
Last edit: Peter Watkins 2013-03-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In Perl "main" is the default namespace. I have never tried running this against a directory of .pl files with no class structure. Try running it against a single .pl files and see what that does, it should work. Let me know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Running against a single file works fine. Of course, I get only a single file in my Doxygen docs. If I did this with every file, I'd end up with a Doxygen doc site for every .pl file. I can think of a few solutions:
1) I can define a new package for every .pl file (this isn't common practice, though)
2) You could change the behavior of PerlDoxygen to treat the main namespace different by default (basically ignore it and make it a non-class). This exception for a specific namespace seems like a bit of a hack, perhaps.
3) You could do the above, just not by default. Perhaps a command-line flag, a config file, or a new Doxygen-style tage, @ignoremainpackage, which gets consumed.
Just some ideas.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have made some changes in 1.60 that might address your previous issues.
Bret
On Mar 27, 2013, at 9:01 AM, Peter Watkins wrote:
Running against a single file works fine. Of course, I get only a single file in my Doxygen docs. If I did this with every file, I'd end up with a Doxygen doc site for every .pl file. I can think of a few solutions:
1) I can define a new package for every .pl file (this isn't common practice, though)
2) You could change the behavior of PerlDoxygen to treat the main namespace different by default (basically ignore it and make it a non-class). This exception for a specific namespace seems like a bit of a hack, perhaps.
3) You could do the above, just not by default. Perhaps a command-line flag, a config file, or a new Doxygen-style tage, @ignoremainpackage, which gets consumed.
Just some ideas.
Several .pl files -- everything goes into the main class
I have several *.pl files that I'm documenting. When I run Doxygen, all the function documentation goes into the "main" class. i.e. it looks like there's one class called "main", shared by every *.pl file.
My code doesn't have any classes--it's not object-oriented Perl. It's just a couple simple scripts with subroutines. Is there any way to keep my documentation out of the "main" class? Is what I'm describing normal behavior?
Last edit: Peter Watkins 2013-03-27
In Perl "main" is the default namespace. I have never tried running this against a directory of .pl files with no class structure. Try running it against a single .pl files and see what that does, it should work. Let me know.
Running against a single file works fine. Of course, I get only a single file in my Doxygen docs. If I did this with every file, I'd end up with a Doxygen doc site for every .pl file. I can think of a few solutions:
1) I can define a new package for every .pl file (this isn't common practice, though)
2) You could change the behavior of PerlDoxygen to treat the main namespace different by default (basically ignore it and make it a non-class). This exception for a specific namespace seems like a bit of a hack, perhaps.
3) You could do the above, just not by default. Perhaps a command-line flag, a config file, or a new Doxygen-style tage, @ignoremainpackage, which gets consumed.
Just some ideas.
I have made some changes in 1.60 that might address your previous issues.
Bret
On Mar 27, 2013, at 9:01 AM, Peter Watkins wrote: