Eclipse project.properties пути обратной косой черты считаются вредными
Я работаю в команде, которая занимается разработкой программного обеспечения для Android. Некоторые члены команды используют Windows, некоторые используют Mac, и я знаю, что я использую Linux. Каждый использует Eclipse.
Eclipse пишет файл с именем project.properties; вот пример. Важной частью являются последние три строки, пути ссылки на библиотеку Android.
# This file is automatically generated by Android Tools.
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
#
# This file must be checked in Version Control Systems.
#
# To customize properties used by the Ant build system edit
# "ant.properties", and override values to adapt the script to your
# project structure.
#
# To enable ProGuard to shrink and obfuscate your code, uncomment this (available properties: sdk.dir, user.home):
#proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt
# Project target.
target=android-17
android.library.reference.1=../private-code/lib/SomeLibrary
android.library.reference.2=../google-play-services_lib
android.library.reference.3=../FacebookSDK
Выше показано, как выглядит файл, когда Eclipse на Mac или Linux пишет его. Когда Eclipse в Windows пишет это, строки ссылок на библиотеку пишутся с обратной косой чертой.
Конечно, в Windows обратные слеши являются приемлемыми разделителями пути. Но на Mac и Linux такие пути не работают. Дело в том, что в Windows прямая косая черта работает отлично. Итак, наша политика теперь всегда заключается в том, чтобы фиксировать файл с косой чертой, чтобы он работал для всех.
Но это боль для наших пользователей Windows, и боль для остальных из нас, когда пользователи Windows делают ошибку, поэтому я ищу техническое решение. У меня есть две идеи:
Найдите параметр где-нибудь в Eclipse в Windows, указав ему использовать косую черту при сохранении путей в таких файлах, как
project.properties, (Почему, черт возьми, это не по умолчанию?!?)Мы используем Mercurial, поэтому: установите какие-то "крючки", которые решат проблему.
- Установите ловушку фиксации на компьютерах Windows, чтобы файл фиксировался в хранилище, а обратные косые черты заменялись прямыми косыми чертами.
- Установите защелки на компьютерах Mac и Linux; поэтому, если файл фиксируется с обратной косой чертой, он исправляется к моменту записи файлов.
Хук фиксации кажется чище, поэтому, если оба доступны, я бы взял хук фиксации поверх тяги.
Я нашел расширение Mercurial, которое редактирует вкладки в пробелы, что, по крайней мере, похоже на то, что я хочу. Это достаточно сложно, поэтому я немного опасаюсь пытаться превратить его в то, что мне нужно.
https://www.mercurial-scm.org/wiki/CheckFilesExtension
Другая стратегия заключается в добавлении ловушки, которая обнаруживает обратную косую черту в путях и просто прерывает фиксацию, заставляя пользователя Windows вручную исправить файл перед фиксацией. Это было бы лучше, чем ничего.
2 ответа
Я хотел бы сохранить обе версии в проекте (как project.properties.windows и project.properties.linux) и создать символическую ссылку, указывающую на нужный файл в зависимости от ОС. Назовите эту символическую ссылку project.properties и пусть она будет игнорироваться системой контроля версий.
Очевидно, что недостатком этой настройки является то, что когда пользователи Windows обновляют свой файл project.properties (который указывает на project.properties.windows), версия linux должна обновляться вручную, и наоборот, но это не звучит как большая сделка, я полагаю, вы не очень часто обновляете этот файл.
- Для создания ссылок -
Создайте файл make_link.sh для настройки среды Linux с помощью следующей команды:
ln -s $(readlink -m project.properties.linux) $(readlink . -m)/project.properties
Создайте файл make_link.bat для настройки сред Windows с помощью следующей команды:
mklink project.properties project.properties.windows
Вы также можете зафиксировать эти скрипты.
Мы столкнулись с подобной ситуацией из-за различий в пути локальной библиотеки, поэтому после некоторого поиска мы обнаружили, что рекомендуется использовать инструменты централизованного репозитория (Git для нас): "Удалите все файлы настроек, зависящие от затмения / специфические, из репозитория". И это прекрасно работает для нас. Таким образом, изменение файла настроек затмения не повлияет на центральное хранилище и не будет зафиксировано.