Would someone be able to verify this for me?<br><br>Thanks,<br>Brian Panneton<br><br><div class="gmail_quote">On Thu, Jan 27, 2011 at 11:58 AM, Brian Panneton <span dir="ltr">&lt;<a href="mailto:brian.panneton@gmail.com">brian.panneton@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I have found an issue with UseSWIG.cmake during parallel builds. If you are swigging Python and Java using the SWIG_ADD_MODULE and SWIG_LINK_LIBRARIES macros you could run into this issue. <br>
<br>When you run through CMake, the macro SWIG_GET_EXTRA_OUTPUT_FILES sets the variable SWIG_EXTRA_GENERATED_FILES. This variable is used by a custom command as an output. When CMaking, it never gets reset. Thus if you start with swigging Python, the file module.py is appended to it. Then when swigging Java, the same file remains as an output. <br>

<br>If you are running in parallel, the output file is claimed by both Java and Python. Somehow this makes it so the Python lib might not get fully built on the first try.<br><br>To solve this issue on the user side we need to reset SWIG_EXTRA_GENERATED_FILES right before you call the macro SWIG_ADD_MODULE, like such:<br>

<br>set(swig_extra_generated_files &quot;&quot;)<br>swig_add_module(${module_name} python module.i)<br><br>To solve this issue on the UseSWIG.cmake side add SET(${outfiles} &quot;&quot;) to the first line of the macro SWIG_GET_EXTRA_OUTPUT_FILES, like such:<br>

<br>MACRO(SWIG_GET_EXTRA_OUTPUT_FILES language outfiles generatedpath infile)<br>  SET(${outfiles} &quot;&quot;)<br>  GET_SOURCE_FILE_PROPERTY(SWIG_GET_EXTRA_OUTPUT_FILES_module_basename<br>    ${infile} SWIG_MODULE_NAME)<br>

<br>I am pretty sure this would solve the issue. Please let me know if this is the correct way to go about it.<br><br>Thanks,<br><font color="#888888">Brian Panneton<br>
</font></blockquote></div><br>