2016-08-24 1 views
0

내 premake 생성 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를 오버라이드 (override)에서 오는 취성을 방지하는 방법을 알고 싶습니다 :

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에서 이런 식으로 뭔가 : vs2005_csproj.lua에서

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

그리고이 :

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

그리고 당신은 당신의 프로젝트 스크립트에서 사용할 수 있습니다 :

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

보너스 포인트 , 당신은 refactor csproj.compilerProps 새로운, 더 ex를 사용할 수 있습니다. 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

Premake와 같은 도구의 핵심은 그러한 종류의 래퍼를 제공하고 기여가 도움이된다는 것입니다. 즉,'compilerProps'가 설명한대로 수정되면 (결국 관계없이 발생해야 함),'m.elements.compilerProps'를 오버라이드하고 거기에 새로운 엔트리를 추가/제거하여 블록에 쓰여지는 것을 변경시킬 수 있습니다. – starkos