2016-08-24 10 views
0

私はプレハークで生成されたVisual Studioプロジェクトで、プロジェクトごとではなくサイトポリシーとしていくつかのプロパティを設定できるようにしたいと考えています。premake5でVSプロジェクトにプロパティを注入する

これは動作する例ですが、理想的ではありません。これは私のpremake5-system.luaスタートアップファイルにあります。 vs2015アクションで使用されるプロジェクトジェネレータをオーバーライドし、プロジェクトプロパティ生成関数を条件付きでオーバーライドします。

premake.override(premake.action._list.vs2015, 'onProject', function(base, prj) 

    -- For C# libraries force static code analysis on. 
    if premake.project.isdotnet(prj) and prj.kind == premake.SHAREDLIB then 
     premake.override(premake.vstudio.cs2005, "compilerProps", function(base, cfg) 
      _p(2, '<RunCodeAnalysis>true</RunCodeAnalysis>') 
      base(cfg) 
     end) 
    end 

    base(prj) 
end) 

私はそれは私が他のVSのバージョンのためにそれを複製する必要があるだろう意味するので、このスニペットは、明示的にVS2015に言及しているという事実が好きではありません。私は、premakeがVSのそれ以降のバージョンで2005年のプロパティエミッタを使用することをやめた場合、これが破損するため、cs2005プロジェクトジェネレータを明示的に言及しているのは好きではありません。

もっと一般的にすることができますか、これは正しいアプローチですか?

更新:

複数のプロジェクトがワークスペースに存在する場合、内部の上書きを複数回追加されますので、onProject(のオーバーライド内でオーバーライドを追加する仕組み)が欠陥があることを私が発見したといくつかのプロジェクトでカスタムプロパティを複数回出力します。ここでは改良版だが、私はまだ直接cs2005を上書きするから来ている脆弱性を回避する方法を知っているしたいと思います:

premake.override(premake.vstudio.cs2005, "compilerProps", function(base, cfg) 

    local prj = cfg.project 

    if premake.project.isdotnet(prj) then 
     _p(2, '<RunCodeAnalysis>true</RunCodeAnalysis>') 
    end 

    base(cfg) 
end) 

答えて

0

私は答えは使用し、新しいプロジェクトのAPIコールを作成することであると仮定新しい値はcsproj.compilerProps、次にsubmit a pull requestです。この機能については何の論争もなく、マージする方が簡単なはずです。そして、オーバーライドを維持する必要はありません。

_premake_init.luaでこのような何か:ボーナスポイント

codeanalysis "On" -- or "true" or "yes" 

vs2005_csproj.lua

api.register { 
    name = "codeanalysis", 
    scope = "config", 
    kind = "boolean", 
} 

そして、この:

if cfg.codeanalysis then 
    _p(2, '<RunCodeAnalysis>true</RunCodeAnalysis>') 
end 

そして、あなたのプロジェクトのスクリプトでそれを使用することができます、あなたは新しい、より多くのexを使用するためにcsproj.compilerPropsをリファクタリングすることができましたvs2010_vcxproj.luaようtensible「コール配列」アプローチ:

m.elements.compilerProps = function(cfg) 
    return { 
     m.defineConstants, 
     m.errorReport, 
     m.runCodeAnalysis, 
     m.warningLevel, 
     m.allowUnsafeBlocks, 
     m.treatWarningsAsErrors, 
     m.commandLineParameters, 
    } 
end) 

function cs2005.compilerProps(cfg) 
    p.callArray(m.elements.compilerProps, cfg) 
end 

function m.defineConstants(cfg) 
    _x(2,'<DefineConstants>%s</DefineConstants>', table.concat(cfg.defines, ";")) 
end 

-- and so on… 
+0

思考が私の心を交差させますが、「基本製品の変更」に新しいプロパティを追加する新しい拡張が頻繁にあるとき、カスタマイズに非常にスケーラブルなアプローチのように感じることはありませんしていましたVSプロジェクトファイル。 makeやVSのようなビルドシステムの違いは、その種のラッピングを提供することによって、インターフェースを正規化する試みを打破する傾向があります。 カスタムプロパティをキー/値のペアとして挿入するためのメカニズムを代わりに追加するのは意味がありますか? premakeが最初にメモリにDOMを構築するのではなく、VSファイルを連続的に書き込むように見えるので、XMLスコープの処理は難しいかもしれません。 – Soleil

+0

プレアケのようなツールの全体は、そのような種類のラッパーを提供することであり、貢献が助けになります。つまり、 'compilerProps'が記述されているように変更された場合(これは関係なく最終的に発生する必要があります)、' m.elements.compilerProps'をオーバーライドして新しいエントリを追加/削除し、ブロックに書き込まれる内容を変更できます。 – starkos

関連する問題