Closed mgalloy closed 9 years ago
Is the definition of star_single_receiver_request available? i.e., is star_single_receiver_request__define.pro in the !path? I got exactly the same error you mention when I hadn't created star_single_receiver_request__define.pro yet, but it works fine with star_single_receiver_request__define.pro in the same directory as star_course_vs_time_receiver_request__define.pro or somewhere else in my !path.
Author: jhood Yes all of the superclasses are in the path for the example. The code itself executes properly. Until a short while ago, all errors of this form (5 over the entire code base) were in depricated code, so I didn't pay much attention. In the last month, I got four new errors of this form, so I decided to try and solve it. It may be something silly that I am doing on my end, but I can't see what the problem would be.
Some of the code doesn't nicely auto-compile and we put includes (@filename) at the top of some applications to make sure that the right code is compiled in order. This is mainly because we will put several functions in the same file. It looks like you might require function calls, etc. to properly compile automatically in order for IDLDoc to understand them. This might be the root of the problem, though in this case the classes are in their own file and properly named to compile automatically. I will look to see if some other function call (i.e. one with a keyword that isn't already defined) could be causing a compile to fail. Would this cause the error?
For what it's worth, we see this error consistently when mgunit tests are parsed via idldoc. The doc output seems ok, but we get this message:
00:00:30.585 % Compiled module: CONFIG_UT__DEFINE.
00:00:30.585 % IDLDOC: cannot construct definition for class config_ut
These test cases inherit MGutTestCase, which is available on the path.
They inherit only from MGutTestCase
?
Yes. Here's the complete class definition for the message referenced above.
pro config_ut__define
compile_opt strictarr
define = { config_ut, inherits MGutTestCase }
end
I can strip down the complete file and send it if that would help.
If you could make a small example that shows the problem and send it to me, that would be great!
I got the same issue you are reporting until I made sure MGutTestCase
was resolved before running IDLdoc. Remember: if you are using the mgunit .sav
file distribution, then you need to RESTORE
mgunit.sav
before running IDLdoc to make MGutTestCase
available (since it will not automatically be found in mgunit.sav
since it has a different name).
Please let me know if this resolves your issue.
Yes, I'm glad it was that easy! I assumed this wasn't necessary since the tests find and resolve mgunit when they are run, but of course they aren't being run when the doc is built. For the record, I added this code to the start of our documentation batch job:
; must restore mgunit.sav or there will be warnings in the log
print, 'Restoring mgunit'
mgunit_path = strsplit(!path,path_sep(/SEARCH_PATH),/extract)
mgunit_path = mgunit_path + path_sep() + 'mgunit.sav'
mgunit_file = file_search(mgunit_path)
if n_elements(mgunit_file) ge 1 then restore, mgunit_file[0] & print, 'Restored mgunit'
Great, I will close this ticket.
By the way, I would do:
mgunit_file = file_which('mgunit.sav')
if (n_elements(mgunit_file) gt 0) then restore, mgunit_file[0] & print, 'Restored mgunit'
Thanks Mike. More library routines to become familiar with...
I think that there is a problem when IDLDoc tries to construct a class definition for a class that just inherits. For example:
Produces the following error:
This doesn't seem to happen all of the time, but I can't find a consistent thread to indicate when this problem occurs and when it doesn't.