MBSのドツボから生還

Eclipse CDT3.x

昨日の続き．

最近生意気な娘を劇叱りしたり，王様のブランチに集中力を殺がれながら，自宅で作業．

昨日見たMLの記事には続きがあった．
曰く

I gave up and used a custom build step. This satisfied my current requirements.

Either there is something wrong with the secondaryOutputs attribute or its usage is so obscure as to be useless.

がーん．

でも諦めない．明かりはさっぱり見えないけれど．

解決…なのか?

USER_OBJSとLIBSが絡んでいることは，ステップ実行の結果，掴めた．
MBSにおいてこの2つのマクロは，Java内の定数にも出てくる，割と特別視されたものだ．
これだけ追いかけてバグっぽい箇所を直感できないのは，久しぶり．いくつかのバグが組合わさった挙動なのかも．

家族が昼食のときも脇目もふらず，小声の独り言が多くなっているのも隠さず，14:30．やっと逃げ方を思いついた．

 	     <inputType
             id="jp.pizzafactory.crosschains.inputType1"
-            buildVariable="EXECUTABLES"
+            buildVariable="filter-out USER_OBJS, $(EXECUTABLES)"
             multipleOfType="true"
             primaryInput="true"
             sourceContentType="org.eclipse.cdt.managedbuilder.core.executableFile"/>

意図的なのかどうかは判らないが，buildVariableの管理が甘いため，下記のようなmakefileが無事に生成される．

default.bin: $(filter-out\ USER_OBJS,\ $(EXECUTABLES))
	@echo '呼び出し中: GNU Objcopy'
	arm-elf-objcopy -Obinary $(filter-out USER_OBJS, $(EXECUTABLES)) "default.bin"
	@echo 'ビルド完了: $@'
	@echo ' '

ああ，逃げているなぁ．でも，org.eclipse.cdt.namagedbuilder.core を改変せずしない解放としては，これくらいしか浮かばない．

まあ，inputType/outputTypeで済む範囲なら，後でクールな解法がみつかったとしても，ユーザに負担かけずにパッチ当てできそうではある．