add targetType "unlinkedObjects"

[WebFreak001]

fix #266

this can be used to generate .o with DMD and also .s and .ll files with LDC. This is useful for having an external linker or build step taking in the unoptimized llvm files for example or cross linking to another system. With LDC it is also possible to compile the code to assembly files using this target type.

All generated object files using this target type are being written into $DUB_TARGET_PATH/obj/. By default this is only .o files (or .obj on windows) but this is completely up to the compiler and dub doesn't restrict anything here. On LDC it's possible to specify -output-ll to output LLVM IR files instead or -output-s to output assembly files instead and they will just be put in the object folder like anything else the compiler generates.

This is pretty much equivalent to passing -c and removing the -of argument and only leaving -od to a user directory.

Example:

buildRequirements "allowWarnings"
buildOptions "betterC"
versions "__AVR_ATmega1284P__"
lflags "--gc-sections"
targetType "unlinkedObjects"
dflags "-mtriple=avr" "-mcpu=atmega1284p" "-output-o" "-Oz" "--fvisibility=hidden" platform="ldc"
postBuildCommands "avr-gcc -mmcu=atmega1284p -Wall -Wl,\"$${LFLAGS// /,}\" $$DUB_TARGET_PATH/obj/*.o -o \"$$DUB_TARGET_NAME.elf\"" "avr-objcopy -O ihex -R .eeprom \"$$DUB_TARGET_NAME.elf\" \"$$DUB_TARGET_NAME.hex\""

this will generate object files for each source file and then afterwards link them together using an external command. In this practical use-case avr-gcc links all the object files together to one elf file and then converts it to a hex file which is ready for flashing on an embedded MCU. This is needed because ldc alone cannot properly perform this linking task.

Currently caching for this is only temporarily implemented for dmd obj files because ldc names the files after the module name (which is what should be done with dmd in the future too) which aren't determined yet.

This PR makes it more feasible to do embedded development and other more complex build types with dub. This is currently required for https://github.com/WebFreak001/avrd and the example use case can be seen in action there. (with also more complex LLVM usage for better optimization)

[dlang-bot]

Thanks for your pull request, @WebFreak001!

[WebFreak001]

bump

[thewilsonator]

@WebFreak001 this is good to go as soon as it is green. Maybe give it another push?

[WebFreak001]

I tried restarting the travis builds but I'm not really sure why it still hangs up in the dependency fetching of dub in old DMD versions. And the ICE on appveyor I'm also not sure what to do about

[wilzbach]

The appveyor failure is unrelated and Travis seems to fail spuriously on other PRs too.

[WebFreak001]

even after the third run it still froze at the same place for both the old DMD versions. Are you sure this is just a random occurrence?

[Herringway]

I'm very interested in this feature. What was the status? It seems to need a rebase now.