title: How can I get MIDL to search additional include directories for qualified paths
body: <p><strong>Update:</strong> Just over six months after opening a support call to Microsoft it has been rejected, they claim it is not a bug (since the documentation doesn't explicitly say that the behaviour seen isn't the correct one). They rejected the <a href="http://www.acronymfinder.com/Design-Change-Request-%28DCR%29.html" rel="nofollow noreferrer" title="Design Change Request">DCR</a> saying that since they haven't heard any complaints in the last 10 years this is obviously not a common use case.</p>
  <p>This is a call to arms, if you have run into the same issue, please open a support call with Microsoft so they understand that it should be fixed. I <strong>know</strong> that at least <em>someone</em> has run into the same problem becasue I found this comment in <a href="http://src.chromium.org/svn/trunk/src/gears/SConscript.browser" rel="nofollow noreferrer">Chrome's source code</a>:</p>
  <blockquote>
  <p><code>#</code> Building .idl files.<br />
  <code>#</code> This is a total mess.  MIDL needs to be run from $OPEN_DIR because it's too<br />
  <code>#</code> stupid to apply its include paths to a relative path like &quot;ui/ie/bla.idl&quot;<br />
  <code>#</code> (it only looks in the current dir).  So we have to jump through hoops to fix<br />
  <code>#</code> up our relative include paths and output files.</p>
  </blockquote>
  <hr />
  <p><strong>Original question:</strong></p>
  <p>I have the following file structure:</p>
  <ul>
  <li><code>C:\first\Foo.idl</code></li>
  <li><code>C:\second\Bar.idl</code></li>
  </ul>
  <p>Where <code>Bar.idl</code> contains the following line:</p>
  <pre><code>import &quot;first/Foo.idl&quot;;
  </code></pre>
  <p>How can I get <strong>midl</strong> to compile <code>Bar.idl</code> when compiling from <code>C:\second</code>?</p>
  <p>If I imported <code>Foo.idl</code> directly (without specifying <code>first/</code>) then specifying <code>first</code> as an additional include directory would be enough (<code>midl /I c:\first Bar.idl</code>) and it would find <code>Foo.idl</code></p>
  <p>Alternately if I compiled from <code>C:\</code> (<code>midl second\Bar.idl</code>) that would be OK too.</p>
  <p>The problem is that when compiling from within <code>C:\second</code> with the command line <code>midl /I C:\ Bar.idl</code>, I get the following compilation error:</p>
  <blockquote>
  <p>c1 : fatal error C1083: Cannot open source file: 'first\Foo.idl': No such file or directory</p>
  </blockquote>
  <p>It looks like <strong>midl</strong> is willing to search relative paths only if they are relative to the current directory and not to one of the specified additional include directories and uses the additional include directories only for unqualified file names, this behaviour is specific to the <code>import</code> keyword, when using <code>include</code> the results are as expected.</p>
  <p>I would like to be able to add two different additional include directories so that if I have the file on my local machine <strong>midl</strong> will take that version, otherwise it will take the file from the server (so <code>chdir</code>ing to the root folder is not an option).</p>
  <p>Is there a way to get around this?</p>