Multi target solution

[amirs]

I have a solution which is multi-targeted.
I’m using a several cross compilers for this job, each for its arch.

I have two problems:
1. Some of the architectures require more from the project, and does not.
which means I can either:
a) #ifdef ARCH_NEED_THIS_CODE
in the .c code to make it compile on that specific arch,
which makes my code ugly
b) edit the SOURCEFILES manually
which makes me lose its auto-generation.

Is there any other solution?
I have tried to use VisualStudio normal way of checking “Excluded From Build” in the file properties page… but it didn’t work.

2. I have lots of configuration duplicates
For each arch, I will want to have two configuration Debug&Release
The only difference between Release&Debug is the #defines & optimization.
The only difference between each arch is the path to the cross compiler, and the target deployment host (building machine is the same)

Is there any way to save the trouble of maintaining so many duplicated configurations?
Is there any way for easy editing? (In VisualStudio you can select multiple projects&configurations while changing a single setting).

[support]

Hi,

You could exclude some source files by replacing this line in Makefile:

all_source_files := $(SOURCEFILES)

with this:

all_source_files := $(filter-out $(EXCLUDED_FILES),$(SOURCEFILES))

Then you can define EXCLUDED_FILES in your per-configuration .mak files to have those files excluded from build.

Regarding configuration reuse, unfortunately there is no direct way. VisualGDB Project Properties editor is way more sophisticated than Visual Studio configuration editor and it heavily relies on the ‘current configuration’ concept (e.g. it substitutes configuration variables on-the-fly, allows browsing files on the currently selected remote machine, etc).
However, you can use the following techniques to reuse some of the settings:
1. VisualGDB Make Settings editor edits the .mak file for the current configuration, it does not regenerate it. You can move the common settings to a separate .mak file (e.g. CFLAGS += -ggdb) and include it from the configuration files.
2. All VisualGDB settings are stored in -.vgdbsettings files. Those files are XML files generated by .Net serializer from public objects inside VisualGDB.EXE assembly. If you are dealing with plenty of configurations you may want to generate those on-the-fly. Using the .Net serializer it’s a very straight-forward process.
3. VisualGDB supports an project extension mechanism that allows creating .Net extensions to automate things not directly supported by VisualGDB. We could extend it with a method to patch the project settings on-the-fly before building or debugging so that you could have only one .vgdbsettings file and a basic extension DLL that sets the architecture-specific parameters based on the platform.

[Author]

Posts