Я смог построить его, следуя инструкциям Сурьмы. Однако изначально я получил эту ошибку:
Bootstrapping the build engine
\Windows was unexpected at this time.
Ошибка была устранена путем очистки переменной PATH и помещения в нее только папки MinGW:
set PATH=C:\MinGW\bin
Затем инструкции сурьмы сделали свою работу для мне. Спасибо !!
Еще две мелочи, которые могут быть полезны. BOOST для MinGW следует собирать из оболочки Windows, а не из оболочки MSYS. А в версии 1.57 скрипт bootstrap.bat больше не находится в tools \ build \ v2, а прямо в tools \ build.
Это ошибка, которая была исправлена между 2.5 и 2.6. Функция fileConfig () предназначена для одноразовой конфигурации и поэтому не должна вызываться более одного раза - однако вы решите это организовать. Предполагаемое поведение fileConfig - отключить любые регистраторы, которые явно не упомянуты в конфигурации, и оставить включенными упомянутые регистраторы и их дочерние элементы; ошибка приводила к отключению детей, хотя этого не должно было быть. В примере конфигурации регистратора упоминаются регистраторы «a» и «b»; после вызова getLogger ('a.submod') создается дочерний регистратор. Второй вызов fileConfig ошибочно отключает это в Python 2.5 - в Python 2.6 регистратор не отключен, поскольку он является дочерним по отношению к регистратору, явно упомянутому в конфигурации.
Интересно ... Я немного поиграл в консоли, и похоже, что второй вызов logging.config.fileConfig
все портит. Не уверен, почему это так ... Вот стенограмма, которая показывает проблему:
lorien$ python2.5
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> import logging.config
>>> logging.config.fileConfig('logger.conf')
>>> alog = logging.getLogger('a.submod')
>>> alog.info('foo')
foo
>>> import logging
>>> import logging.config
>>> alog.info('foo')
foo
>>> logging.config.fileConfig('logger.conf')
>>> alog.info('foo')
>>> alog = logging.getLogger('a.submod')
>>> alog.info('foo')
>>>
>>> blog = logging.getLogger('b.submod')
>>> blog.info('foo')
foo
>>>
Как только я вызываю logging.config.fileConfig
во второй раз, мой экземпляр регистратора прекращает регистрацию. Захват нового экземпляра журнала не помогает, поскольку это тот же объект. Если я подожду, пока оба раза не настрою загрузку экземпляров регистратора, тогда все заработает - вот почему работает экземпляр blog
.
Я предлагаю отложить захват экземпляров регистратора до тех пор, пока вы не войдете в функции . Если вы переместите вызовы logging.getLogger ()
в function_one
и function_two
, тогда все будет хорошо.
Я сам не понимаю причин такого поведения, но, как вы хорошо сказали в 2.6, он работает по-другому. Мы можем предположить, что это ошибка, затрагивающая 2.5
В качестве обходного пути я предлагаю следующее:
extra_module.py:
import logging
import logging.config
logging.config.fileConfig('logger.conf')
a_log = logging.getLogger('a.submod')
b_log = logging.getLogger('b.submod')
module_one.py:
from extra_module import a_log
def function_one():
a_log.info("function_one() called.")
module_two.py:
from extra_module import b_log
def function_two():
b_log.info("function_two() called.")
, используя эту схему, я был возможность запускать logger.py на python2.5.4 с тем же поведением, что и в версии 2.6
Мне удалось это исправить, изменив имена регистраторов в обоих файлах следующим образом:
logging.config.fileConfig('logger.conf')
a_log = logging.getLogger('a')
b_log = logging.getLogger('b')
Я не уверен в точной ошибке, но модуль регистратора v2.5, кажется, возникают проблемы с сопоставлением имен, переданных в getLogger ()
, с именами в файле конфигурации.