Rename exporter configurations


#1

In order to build both x86 and x64 versions for Windows, you usually have to add two different Visual Studio exporter configurations - one for each architecture - and let them use different target folders (let's say Builds/VS2013 and Builds/VS2013_x64).

Now, it would be nice if you could give those exporter configurations different names inside Introjucer, instead of referring to both of them as "Visual Studio 2013". Not only to make it more clear, but also to remove the confusion when trying to use the "Save and open in Visual Studio" option. It presents a popup menu with all the relevant Visual Studio exporters, but they currently have the same name. Not possible to see which one is x86 and which one is x64.

So, could it be possible to give each exporter config its own name?


#2

Good request! Will add it to our backlog..


#3

Bump, any news on this? Is it still in backlog?

Really minor issue, yes, but nevertheless the name confusion keeps stealing time from us on a daily basis when working with Introjucer / Projucer.


#4

Hm. Whenever I need separate x86 and and x64 configurations, I always use one exporter and then simply add additonal configurations and rename them accordingly:

 

Works just fine for me. Introjucer puts it all nicely into a single VS solution and then when I'm compiling I can select the desired configuration in the drop-down menu inside Visual Studio.

Am I missing something here?


#5

There are reasons why i choose to use separate exporters (for example different linker objects for architectures, other compiler flags, other icons, separate demo-build), and it works perfect besides you cannot rename the exporters.

Besides Introjucer should also check if the exporter share the same output-folder and should warn or prevent this wrong configuration.


#6

Timur, there was previously an issue with the method you described, see this old post from me (about the binary locations):

http://www.juce.com/forum/topic/visual-studio-win32-x64-platforms

But maybe that has been resolved, in which case it's good news!

 

However, as mentioned by chkn, there are often reasons for still using the other method, especially when linking static libraries with the project. So the renaming possibility would be very welcome.


#7

The issue you are citing is fixed. If you use the configurations I suggested above (with a single Visual Studio exporter), then Visual Studio 2015 will put its 32-bit build products into Debug/ and Release/ and the 64-bit build products into x64/Debug64/ and x64/Release64/, respectively.

Also, you can specify library search paths per configuration, so linking different static libraries for different configurations of the same exporter shouldn't be a problem either.


#8

Excellent! I will consider switching to your suggested method then.


#9

still want renaming exporters (it would be okay, if just the output folder name is displayed as exporter name)