Visual Studio makro z ścieżkę rekwizytów złożyć

Question

Krótkie pytanie:

Chcę móc używać ścieżkę rekwizytów plik jako makro od wewnątrz podpór pliku (jak zdolność do odwoływać katalog projekt jako $(ProjectDir))

długo pytanie

używam pliki rekwizyty, aby dodać odniesienie do różnych bibliotek 3rd party.

Jest to proste, jeśli mogę podać bezwzględną ścieżkę do biblioteki trzeciej.

Jednak chcę podać względną ścieżkę - ponieważ różni członkowie zespołu używają innej lokalizacji dla drzewa kontroli źródła. Czy istnieje metoda dodawania takich względnych ścieżek do pliku rekwizytów?

określania ścieżki względnej do katalogu projektu nie jest dobrym rozwiązaniem zarówno, jako lokalizacja projektów nie jest stały (tak dla jednego projektu I musiałaby $(SolutionDir)\..\XXXX i innym będę potrzebował $(SolutionDir)\..\..\XXXX

Answer 1

Sugerowałbym, że masz sprzeczne interesy:

1. Zapewnić pliki rekwizyty, że wszyscy deweloperzy użyciu i eliminuje potrzebę dla programistów, aby zakwalifikować #include ścieżki
2. Zezwalaj wszystkim deweloperom, aby określić lokalizację korzeniowy tych #include ścieżek.

To nie jest odpowiedź, której szukałeś, ale proponuję zastosować inne podejście.

Dwa przychodzą na myśl:

1. Niech każdy deweloper definiować makra w czasie kompilacji w pliku Microsoft.Cpp.x64.user, takie jak $(MY_PROJECT_ROOT), aw sprawdzone w pliku rekwizyty określić katalogi w stosunku do tych makr.

2. Użyj ścieżki bezwzględnej w pliku rekwizytów, ale uczyń tę ścieżkę bezwzględną punktem połączenia, taką jak X:\. Każdy programista określiłby, gdzie znajduje się X:\.

Numer 2 ma tę zaletę, że łatwiej jest przełączać się między pniami. Być może, powiedzcie, że wersja 1.0 aplikacji jest wersją Beta 2.0 aplikacji. Możesz użyć tego samego pliku rekwizytów w obu; programista po prostu uruchamia plik wsadowy, aby przełączać skrzyżowania podczas przenoszenia z jednego pnia do drugiego.

Jednak liczba 1 ma tę zaletę, że jest rozwiązaniem całkowicie zamkniętym w środowisku IDE.

Answer 2

@John Dibling: To złe rozwiązanie dla każdej grupy działającej na współbieżnych oddziałach; trzeba cały czas przełączać środowisko lub lokalnie edytować pliki .props w każdej gałęzi. To żałosne, gdy ciągle zmieniasz gałęzie.

Niestety, nie mogę znaleźć lepszego rozwiązania. W mojej głowie byłoby to coś, co na najwyższym poziomie.rekwizyty definiują makro użytkownika takie jak PROJECT_ROOT (zdefiniowane jako "../../"), a następnie inne pliki .props dziedziczą i używają tego makra. W ten sposób możesz udostępnić jeden plik .props rozwiązaniom w wielu różnych ścieżkach względnych. Niestety wygląda na to, że makra użytkownika nie są dziedziczone w plikach .props.

Musi istnieć prawdziwe rozwiązanie, które nie wymaga lokalnie konfigurowania środowiska kompilacji ze względu na statyczną strukturę katalogów w wielu oddziałach.

EDIT:

Wygląda na to, że znalazł rozwiązanie do tego, naprawdę. Zasadniczo masz jeden plik relativepath.props, który definiuje makro użytkownika ze względną ścieżką, inny plik rekwizytów, który używa tego makra dla wszystkich jego ścieżek, a następnie plik, który faktycznie importujesz do twojego vcxproj będzie wyglądał tak, w tym oba arkusze właściwości . Jest to jedyny sposób, w jaki mogę uzyskać to makro z jednego pliku w innych plikach.

Następnie różne rozwiązania w różnych ścieżkach względnych mogą korzystać z różnych ścieżek, podczas gdy właściwości są zdefiniowane tylko raz w pliku realprops.props.

<ImportGroup Label="PropertySheets"> 
     <Import Project="relativepath.props" /> 
     <Import Project="realprops.props" /> 
    </ImportGroup> 

Answer 3

Rozwiązaniem jest: $(MSBuildThisFileFullPath) (or, rather $(MSBuildThisFileDirectory)). _{(co jest odnotowane w przejściu here.)}

Jeśli jest używany w pliku arkusza właściwości (.props) będą odnosić się do tego samego pliku nieruchomość/dir. (Uwaga: W przypadku stosowania na poziomie .vcxproj, że skieruje do pliku projektu/dir

testowane z VS2013 i VS2010 RC