Что такое хорошая поисковая система исходного кода? [закрытый]
Существует несколько способов моделирования того, что вы хотите:
1) Поверните двоичные файлы к примерам
Примеры и тесты построены с помощью dev-dependencies, поэтому вы можете перенести эти зависимости в этот раздел. Библиотека не будет зависеть от них.
# File structure
conformal/
Cargo.toml
src/
lib.rs
examples/ # <-- the `ucitest` is
ucitest.rs # <-- moved to here
# Cargo.toml
[dependencies]
kdtree = { path = "../kdtree" }
rand = "0.3"
[dev-dependencies] # <-- move the examples-only dependencies here
serde = "1"
csv = "0.15"
crossbeam = "0.3"
num_cpus = "1"
[lib]
name = "conformal"
[[example]] # <--- declare the executable
name = "ucitest" # <--- as an example
Для запуска двоичного файла используйте:
cargo run --example ucitest
2) Дополнительные зависимости с требуемыми функциями
Зависимости могут быть сделаны опционально , поэтому другим ящикам, которые зависят от вашей библиотеки conformal, не потребуется их загружать.
Начиная с Rust 1.17, бинарные файлы могут объявить, что они требуют некоторых дополнительных функций, которые должны быть включены, что делает эти библиотеки «необходимыми только для двоичных файлов».
# Cargo.toml
[dependencies]
kdtree = { path = "../kdtree" }
rand = "0.3"
serde = { version = "1", optional = true } # <-- make
csv = { version = "0.15", optional = true } # <-- all of
crossbeam = { version = "0.3", optional = true } # <-- them
num_cpus = { version = "1", optional = true } # <-- optional
[lib]
name = "conformal"
[features]
build-binary = ["serde", "csv", "crossbeam", "num_cpus"]
[[bin]]
name = "ucitest"
required-features = ["build-binary"] # <--
Обратите внимание, что вам необходимо вручную передать --features build-binary при создании двоичных файлов:
cargo run --features build-binary --bin ucitest
3) Сделать двоичные файлы как свой собственный пакет
Вы можете делать любое управление зависимостями, которое вам нравится, когда библиотека и двоичный файл отдельные пакеты.
# File structure
conformal/
Cargo.toml
src/
lib.rs
ucitest/ # <-- move ucitest
Cargo.toml # <-- into its own
src/ # <-- package.
main.rs
# ucitest/Cargo.toml
[dependencies]
conformal = { version = "0.1", path = "../" } # <-- explicitly depend on the library
serde = "1"
csv = "0.15"
crossbeam = "0.3"
num_cpus = "1"
9 ответов
20 минут возмутительны! Я работаю с миллионом + основа исходного кода строки в эти дни и держу, занимает несколько секунд самое большее (я использую ack). Наши корневые каталоги хранятся на файловом сервере и монтируются по NFS, и ускорять захват, мы делаем это, в то время как зарегистрированный к файловому серверу. Я не уверен, сколько времени это принимает NFS, но это, конечно, длиннее.
Мы также делаем операции управления исходным кодом, в то время как зарегистрированный к файловому серверу по тем же причинам производительности.
На Linux я использую идентификатор GNU Utils , Они имеют подобные функции к grep, но работа от индекса, таким образом, они невероятно быстры. Вы выполняете mkid для создания индекса и затем одной из других утилит, таких как "ценуроз", который является идентификационной версией Инструментов grep к grep через индекс. У меня есть задание крона, которое иногда выполняет mkid.
инструменты ID работают над Windows также, или с cygwin или как стандартная Windows-программа
Lxr работает отлично на больших кодовых базах, как доказано с ядро Linux . Я думаю, что это только для C (Вы не определили используемые языки).
Если у Вас есть так много исходного кода, Вы, возможно, должны поместить немного времени в установку поисковой системы для индексации его. Я рекомендовал бы Lucene - его свободное, его быстрое, это, довольно легко настроить мощный индекс на любом содержании для любого с программированием опыта.
Так как Вы говорите 'grepping', я предполагаю, что Вы не незаинтересованы решениями командной строки.
инструмент А как ctags будет индексировать и искать C# и кодовые базы JavaScript (среди многих других).
то, Что очень аккуратно о ctags, - то, что он может быть объединен с энергией или с taglist плагином, чтобы позволить просмотру исходного кода или с энергией omnicomplete включать завершение кода.
Возможно, необходимо инвестировать некоторое время и/или деньги в редакторе или IDE, который поддерживает метки символа. Только необходимо сделать одну передачу через все исходное дерево для меток его, и после этого редактор использует поиск по индексу или поиск карты для нахождения определения символа или ссылок.
Некоторыми примерами редакторов или IDE, которые поддерживают метки, является Eclipse, Visual Studio, SlickEdit. Некоторые IDE могли бы назвать функцию Symbol Browser или что-то подобное.
Некоторое время я использовал cs2project , это система поиска кода C # с открытым исходным кодом, основанная на Lucene.NET. К сожалению, он больше не разрабатывается.
См. Нашу поисковую систему исходного кода SD . Знание языков и обработка многих языков (C, C ++, C #, Java, ObjectiveC, PHP, VB.net, VB6, Ada, Fortran, COBOL, ...). Требуется 2,8 секунды для поиска в ядре Linux (7,3 миллиона строк, 18000+ файлов).
Поскольку он знает язык, он может игнорировать языковые элементы, не относящиеся к вашему поиску (например, игнорировать комментарии, форматирование и пробелы, если вы только интересуется идентификатором или выражением). Он может искать внутри идентификаторов, строк и комментариев. Если вы действительно этого хотите, у него есть возможность поиска по строкам с полным регулярным выражением.
Он использовался для систем, содержащих десятки миллионов строк кода, и в одном известном нам случае в системе с более чем миллионом строк кода. файлы.