Projucer creates duplicate C|Include entries for module headers


#1

Since a few changes on develop I’m running into a strange problem with Projucer and the visual studio 2017 exporter. It creates duplicate include entries in the .vcxproj files of the shared code part of my projects. When loading the solutions in VS2017 I get error messages like: "Cannot load project with duplicated project items: …\JUCE\modules\juce_audio_basics\juce_audio_basics.h is included as “C|Include” and as “C|Include” types.

I checked inside the vcxproj files and there are double entries written by Projucer for each module:

<ClInclude Include="..\..\..\..\..\..\..\JUCE\modules\juce_audio_basics\synthesisers\juce_Synthesiser.h"/>
<ClInclude Include="..\..\..\..\..\..\..\JUCE\modules\juce_audio_basics\juce_audio_basics.h"/>
<ClInclude Include="..\..\..\..\..\..\..\JUCE\modules\juce_audio_basics\juce_audio_basics.h"/>
<ClInclude Include="..\..\..\..\..\..\..\JUCE\modules\juce_audio_devices\audio_io\juce_AudioDeviceManager.h"/>

Anyone else getting this? To me it happens for all my projects (with similar setups) on multiple machines, but not for some JUCE demo projects, so it might be related to a specific setting I’m using.


#2

Not helpful I know, but I had this a couple of weeks ago - I can’t remember what I did to get rid of it I’m afraid. I presume you have the latest Projucer built?


#3

Yes this happens since I pulled the latest changes. Unfortunately I don’t know when I last built the Projucer on windows before the problem appeared. I’m trying to go back, but so far no luck. I guess something in the past silently messed up my projects.


#4

I have a feeling I may have deleted the whole VisualStudio directory from the Builds directory and then resaved/rebuilt… Sorry, really having trouble remembering :frowning:


#5

I tried this already without success. I now switched to the JUCE master branch and the projucer built with that produces correct vcxproj files again - so it has got to be related to one of the recent develop branch changes to Projucer in combination with some settings I am using.


#6

This is strange. I can’t say I’ve ever seen it, and I can’t really see any recent changes which might cause it. It’d help to track it down if you could send over a simple test project which exhibits the behaviour as I can’t reproduce it with any of the JUCE example projects.


#7

Thanks for having a look. I also have no issues with the Juce demo projects. So I guess it’s a combination of a change and my specific project configuration.
Unfortunately I don’t have the time today, but I will figure out which commit causes it on develop as soon as I can. I just takes quite some time do to all those Projucer rebuilds.


#8

I tried finding the exact commit on develop that would introduce the problem and went through a lot of rebuilds of ProJucer, but now the problem is gone on that machine even on the tip of develop.

I still have the issue on my laptop, so it’s definitely weird, but most likely not caused by Juce code, but by either Windows/Visual Studio updates or git somehow.


#9

I found out where the problem happens. It’s related to an assert after line 123 in juce_File.cpp:

if (path.startsWithChar (getSeparatorChar()))
{
    if (path[1] != getSeparatorChar())
    {
        jassertfalse;

Since some time I was hitting this assert when doing debug builds for Projucer on windows, but I never knew why.

The reason why it was hit is: When Projucer is building the module list in getAllPossibleModulePathsFromExporters(…) it also searches the OSX path for some reason unknown to me. For a long time I have been using an absolute Juce path on OS X and thus my module path is “/JUCE/modules”. This path fails the assert as it is invalid on windows. On release builds (where the assert is ignored) this appears to confuse things since some of the latest commits and I end up with these double entries.

I notice that juce demo projects use a relative JUCE path for modules on OS X “~/JUCE/modules”. That’s why they don’t have this issue for me.

I guess I could just move my JUCE folder to my user directory on OS X and that would fix things as it would no longer attempt to deal with an absolute path. Or I could patch Projucer on windows, now that I know where the problem comes from.

Even better would be a fix to Projucer so it doesn’t ever search the OS X path on a windows machine. I don’t understand how that could ever be needed, but if I read right it just goes through all the exporters and collects all paths. I imagine linux paths could also mess things up.

Unless the issue is caused by files living in weird places on my machines I think a way to reproduce it on Windows would be to go to the Modules section, choose any module and set Path for “Xcode (MacOSX)” to “/JUCE/modules” instead of “~/JUCE/modules”. Then export the VS2017 project.


#10

As the release of JUCE 5.4 might lead to some more people running into this and to sum up my late night long post: If you are running into this issue and are using a global module path on OS X, a possible fix is to move the JUCE folder to your user folder on OS X and reconfigure your projects.


#11

ah yes, that’s what I did :slight_smile:


#12

Thanks for looking into this. What is the call stack when you hit that assertion? Looking at getAllPossibleModulePathsFromExporters() it calls Project::resolveFilename() when creating the list of files, which will use File::createFileWithoutCheckingPath() for absolute paths so you shouldn’t be hitting it.


#13

I made a screenshot. The value of path is actually “\JUCE\modules\modules” at some point - which makes no sense at all, but it still shows how somehow the absolute OSX path ends up triggering the assert and somehow leading to these double entries. I am getting tons of these asserts when I open my projects… so it might be another value of path that leads to partially double-detecting module headers. Let me know if you need more info. I’ll keep my laptop in the problematic state for now.


#14

There is another stack trace on later asserts that doesn’t come from getAllPossibleModulePaths…, but from getExtraDependenciesNeeded.


#15

The only spot these paths could possibly come from in my (absolute OS X path) setup is here: It’s not the global module path.


#16

It might be unrelated, but be aware, that on every platform the Projucer creates all exporters, so the XCode projects are also generated, if you click save project on windows.

But Mac paths shouldn’t end up in the windows project, so that doesn’t mean there is no problem.


#17

Right… and this assert has been triggering for a while for me when I didn’t end up with duplicate entries. All I can say for sure is if set the condition before the assert to (false) then the duplicate .vcxproj entry issue is gone.


#18

Using the collected info I can provide exact steps to reproduce the issue.

  • build Projucer in release mode (to avoid hitting the assert)
  • create the GainPlugin example
  • go to the properties of the juce_audio_basics module
  • disable “Use global Paths”
  • set the “Path for XCode” to “/JUCE/modules”
  • save the Visual Studio Solution using the “Save and open in IDE” button.
  • Visual Studio now complains it can’t open the solution and reloading the shared code project shows the duplicate warning. Inspecting the shared code vcxproj in a text editor shows the double entries.

#19

OK I can reproduce the assert now (although not the double entries in the .vcxproj file strangely) but only after adding a C:\JUCE\modules directory to my machine - without it this line would return false and the path would never get added.

Can you try adding the following to line 1927 and see if it fixes the solution load error?

if (! exporter->mayCompileOnCurrentOS())
    continue;

#20

Doing it like that fixes the duplicate thing for me.
However I think this change would break exporting projects for IDEs on different platforms. The currentOS should not matter, but the target of the exporter should match the platform the paths are suitable for.