One problem is that FILTER_PATTERNS expects an executable as an argument, while you give it an executable (perl) and an argument (m2cpp.pl).

If you would wrap "perl m2cpp.pl" into a batch file (that passes its arguments along) then it should work as expected.

Created attachment 244769 [details]
This is an other example where I use an exe-filter that works without an additional interpreter

Hello Dimitri.

I tried it out but I was not able to make it working. Furthermore I have the same effect with an exe-filter as you can see in the second added example.

Even if you think that this is all the wanted behaviour, it may be necessary to add some more examples in the documentation. Especially for those which are not working with unix-filters or those who are using windows may some more background information very useful. Another source of confusion may be the fact that you use for INPUT_FILTER an other kind of value-definition.

Best regards,
                    Eckard Klotz.

Hello Dimitri

In the meanwhile I updated my doxygen-installation to 1.8.4 and tried out the behaviour of the configuration of  the FILTER_PATTERNS.
It is still the same like described for doxygen 1.8.3.1.

It doesn't matter if the filter is a script where I have to mention the script-interpretor also ( first example  with a perl based filter for matlab) or if the filter is a independent exe-file only ( second example with an exe-fileter for pascal).

You mention that the use of a batch-script is the solution. Is it possible for you to use both examples I added to my bug-report for creating examples how to use both filters with a windows bath-file?
Will this batch-file also be usable for  INPUT_FILTER?

Best regards,
                    Eckard Klotz.

Hi Eckard,

I tried your example with the following batch file:

--- runm2cpp.pl ------------
perl m2cpp.pl %*
----------------------------

And with the following settings in the config file:

FILTER_PATTERNS = "*.m=runm2cpp.bat"

And it seemed to work find. You can use the same approach with INPUT_FILTER as well.

In your other example I used the following succesfully:

FILTER_PATTERNS = "*.pas=pas2dox.exe"

Note that I removed the space after =

Also note that you can run doxygen with '-d ExtCmd' option to see how doxygen invokes external commands, and you can use '-d FilterOutput' option to let doxygen dump the output after running it through your filter.

Let me know if this helps locating/fixing the problem.

Hello Dimitri.

I can confirm that the delete of the space after the = solves the problem with an exe-file. But I'm still not able to solve the perl-problem with a batch-file. The m-file seems to be analysed but instead of the expected function doxygen shows a variable called __pad0__ what is not defined in the analysed file. Actualy there is nothing called __pad0__ in the analysed file.

I attached in my example-zip the shell outputs of doxygen as text-files one with using my first solution with only one " and an other one using the batch-file "m2cpp.bat". I called doxygen with the batch-file "Doxygen.bat" to call it with the option '-d FilterOutput'. 

If I use my " solution the filter output contains only the pseudo c-code. But with the batch-file the filter-ouput contains some additional windows-echos also wich may result in an unvalide code for doxygen. I tested some variants for example a batch-file that contains:

 echo off
 perl m2cpp.pl %*

I tried to change the star behind the % into a number .... all with the same result. Calling the perl-filter with windows-batch (windows xp service-pack 2) results into additional lines in the filter output and in wrong doxygen result.

As fazit I can say the batch-filter will be called and that was not the case with two ". But since the filter output seems to be corrupted doxygen is not able to deliver the wanted results.

Please take a look into my attached archive, perhaps you will find something like the space after the = in my exe-example. Furthermore if you have a running example is it possible for you to add it as attachment to this topic?

Thanks for your help and best regards,
                                       Eckard.

Created attachment 248327 [details]
Call a perl-filter by using a windows batch-file

The text-file "doxygen_batch.txt" contains the doxygen shell-output with using a bacht-file.
The text-file "doxygen_both.txt" contains the doxygen shell-output with calling the perl-script inside the the doxygen config-file with only one ".

Both text-files contain the filter-output also.

Hello Dimitri.

Unfortunatly I'm not able to configure Doxygen 1.8.5 in a way that it behaves different compared to teh versions before. After your last comment I added my results. I hope you find some time to check them.

In the case that you finde some errors in my configuration or batch-file, it would be nice if you correct my exmples so that they work and post them again. I assume that I only misunderstood your advise. Thus the posting of working examples would be very helpful. 

Please take a look to the generated files in my example. You will see that something would be generated (that was not the case without useing a batch-file). But the result is not like expected. Please see my post before where I mentioned that a variable __pad0__ was part of the documentation without beeing part of the documented matlab-source.

Best regards,
              Eckard.

The bug is present in 1.8.7 (on windows) also.

Recipe to reproduce:
* doxgen -g
* Set
FILTER_PATTERNS        = *.cpp="gawk -f test.awk"
in Doxyfile
* create test.awk with
###
{
  print $0
}
###
and test.cpp with
###
/// my class
struct A
{

};
###

Running doxygen -d ExtCmd gives:
...
Preprocessing H:/XXX/test.cpp...
Executing popen(`"gawk -f test.awk" "H:/XXX/test.cpp"`)
gawk: fatal: can't open source file `test.awk H:/XXX/test.cpp' for reading (Invalid argument)
...

With the additional escaped quote
FILTER_PATTERNS        = *.cpp="gawk -f test.awk\""

I get no error as
...
Executing popen(`"gawk -f test.awk"" "H:/XXX/test.cpp"`)
...
works.

As far as I can see this is a duplicate of bug_504305

*** This bug has been marked as a duplicate of bug 504305 ***