Почему инструменты сборки использования как Автоинструменты, когда мы можем просто записать наши собственные make-файлы?
Если вы просто хотите перемешать строки (без особой логики), вы можете сделать это несколькими способами:
Используя string_utils:
import string_utils
print string_utils.shuffle("random_string")
Используя встроенные методы:
import random
str_var = list("shuffle_this_string")
random.shuffle(str_var)
print ''.join(str_var)
Используя numpy:
import numpy
str_var = list("shuffle_this_string")
numpy.random.shuffle(str_var)
print ''.join(str_var)
Но если вам нужно сделать это с определенную логику (например, поместить каждый элемент в определенную позицию), вы можете сделать это:
s = 'some_string'
s = ''.join([list(s)[i] for i in [1,6,2,7,9,4,0,8,5,10,3]])
print(s)
Вывод:
otmrn_sisge
Если это все еще занимает слишком долго, вы можете использовать многопроцессорность. Как это:
from multiprocessing import Pool
p = Pool(4) # 4 is the number of workers. usually is set to the number of CPU cores
def shuffle_str(s):
# do shuffling here, and return
list_of_strings = [...]
list_of_results = p.map(shuffle_str, list_of_strings)
5 ответов
Вы говорите приблизительно две отдельных, но переплетенных вещи здесь:
- Автоинструменты
- Стандарты кодирования GNU
В Автоинструментах у Вас есть несколько проектов:
- Autoconf
- Автосделать
- Libtool
Давайте посмотрим на каждого индивидуально.
Autoconf
Autoconf легко сканирует существующее дерево, чтобы найти его зависимости и создать настраивать сценарий, который будет работать почти под любым видом оболочки. Настраивать сценарий позволяет пользователю управлять поведением сборки (т.е. --with-foo, --without-foo, --prefix, --sysconfdir, и т.д.), а также выполнение проверок, чтобы гарантировать, что система может скомпилировать программу.
Настройте генерирует a config.h файл (из шаблона), который программы могут включать для работы вокруг проблем мобильности. Например, если HAVE_LIBPTHREAD не определяется, используйте ветвления вместо этого.
Я лично использую Autoconf на многих проектах. Обычно людям требуется некоторое время для привыкания к m4. Однако это действительно экономит время.
У Вас могут быть make-файлы, наследовали некоторые значения, которые настраивают, находит без использования, автоделают.
Автосделать
Путем обеспечения короткого шаблона, который описывает, какие программы будут созданы и какие объекты должны быть связаны для создания их, могут автоматически быть созданы Make-файлы, которые придерживаются стандартов кодирования GNU. Это включает обработку зависимости и все необходимые цели GNU.
Некоторые люди находят это легче. Я предпочитаю писать свои собственные make-файлы.
Libtool
Libtool является очень классным инструментом для упрощения здания и установки общих библиотек по любой подобной Unix системе. Иногда я использую его; другие времена (особенно, просто создавая статические объекты ссылки) я делаю это вручную.
Существуют другие опции также, видят Альтернативы вопроса о StackOverflow Autoconf и Autotools?.
Build automation & GNU, кодирующая стандарты
Короче говоря, действительно необходимо использовать некоторую портативную систему конфигурации сборки при выпуске кода к массам. То, что Вы используете, ваше дело. Программное обеспечение GNU, как известно, создает и работает почти на чем-либо. Однако Вы, возможно, не должны были бы придерживаться такого (и иногда чрезвычайно педантичный) стандарты.
В любом случае я рекомендовал бы дать Autoconf попытку, если Вы пишете программное обеспечение для систем POSIX. Просто, потому что Автоинструменты производят часть среды сборки, это совместимо со стандартами GNU, не означает, что необходимо следовать тем стандартам (многие не делают!) :) Существует много других опций, также.
Править
Не бойтесь m4 :) всегда существует архив макроса Autoconf. Много примеров или понижение проверок. Запишите свое собственное или используйте то, что тестируется. Autoconf слишком часто путается с, Автоделают. Они - две отдельных вещи.
В первую очередь, Автоинструменты не являются непрозрачной системой сборки, а слабо связанным набором инструментальных средств, как tinkertim уже указанный. Позвольте мне просто добавить некоторые мысли о Autoconf и Automake:
Autoconf является системой конфигурации, которая создает настраивать сценарий на основе проверок функции, которые, как предполагается, работают над всеми видами платформ. Большое системное знание вошло в его m4 макро-базу данных в течение 15 лет его существования. С одной стороны, я думаю, что последний является главной причиной, Автоинструменты еще не были заменены чем-то еще. С другой стороны, Autoconf раньше был намного более важным, когда целевые платформы были более неоднородными и Linux, AIX, HP-UX, SunOS..., и должно было поддерживаться большое разнообразие другой архитектуры процессора. Я действительно не вижу его точку, если Вы только хотите поддерживать недавние дистрибутивы Linux и совместимые с Intel процессоры.
Автосделайте уровень абстракции для GNU, Делают и действия как генератор Make-файла из более простых шаблонов. Много проектов в конечном счете избавились от Автосделать абстракции и вернулись к записи Make-файлов вручную, потому что Вы теряете контроль над своими Make-файлами, и Вам, возможно, не понадобились бы все консервированные цели сборки, которые запутывают Ваш Make-файл.
Теперь к альтернативам (и я настоятельно рекомендую альтернативу Автоинструментам на основе Ваших требований):
Самый известный успех CMAKE заменяет AutoTools в KDE. Это является, вероятно, самым близким, можно добраться, если Вы хотите иметь подобную Autoconf функциональность без m4 особенностей. Это приносит поддержку Windows таблице и, оказалось, было применимо в крупных проектах. Моя говядина с CMake - то, что это - все еще генератор Make-файла (по крайней мере, на Linux) со всеми его постоянными проблемами (например, отладка Make-файла, подписи метки времени, неявный порядок зависимости).
SCons является Сделать заменой, записанной в Python. Это использует сценарии Python в качестве файлов управления сборкой, позволяющих очень сложные методы. К сожалению, его система конфигурации не на одном уровне с Автоконференцией. SCons часто используется для внутренней разработки, когда адаптация к конкретным требованиям более важна, чем следующие конвенции.
Если Вы действительно хотите придерживаться Автоинструментов, я настоятельно рекомендую читать Рекурсивный, Делают Продуманными Вредный и пишут Ваш собственный Make-файл GNU, настроенный через Автоконференцию.
Для маленьких проектов или даже для крупных проектов, которые только работают на одной платформе, рукописные make-файлы являются способом пойти.
То, где автоинструменты действительно сияют, - когда Вы компилируете для различных платформ, которые требуют различных вариантов. Автоинструменты часто являются мозгами позади типичного
./настраивать
сделать
сделайте установку
компиляция и установка ступают для библиотек Linux и приложений.
Тем не менее я нахожу, что автоинструменты боль, и я искал лучшую систему. В последнее время я использовал bjam, но это также имеет его недостатки. Удача, находящая, что работы для Вас.
Автоинструменты необходимы, потому что Make-файлы, как гарантируют, не будут работать то же через различные платформы. Если Вы пишете от руки Make-файл, и он работает над Вашей машиной, существует хороший шанс, что он не будет на моей.
Вы знаете, какой Unix Ваши пользователи будут использовать? Или даже который распределение Linux? Вы знаете, где они хотят установленное программное обеспечение? Вы знаете, какие инструменты они имеют, на какой архитектуре они хотят скомпилировать, сколько центральных процессоров они имеют, сколько RAM и диска могло бы быть доступно им?
*отклоняют мир, межплатформенная среда, и Ваша сборка и инструменты установки должны иметь дело с этим.
Обратите внимание, автоматическое* дата инструментов с более ранней эпохи, и существует много допустимых жалоб на них, но эти несколько проектов заменить их более современными альтернативами испытывают затруднения при разработке большого импульса.
Много вещей похоже, это в *отклоняет мир.