Логин:   Пароль:   
   
 
X   Сообщение сайта
(Сообщение закроется через 2 секунды)
 
> Вопросы и ответы, Тема для различных мелких вопросов
IRonHulk
сообщение 11.8.2012, 1:09
Сообщение #221


Новенький


Группа: Пользователи
Сообщений: 55
Регистрация: 2.12.2009
Пользователь №: 115666
Спасибо сказали: 3 раз(а)



Цитата(debian @ 9.8.2012, 20:50) *
многообуквоф

На самом деле, freeradius умеет отдавать все нужные атрибуты, попробуйте его.
 
+Цитировать сообщение
spy
сообщение 17.1.2013, 14:03
Сообщение #222


Психопат
Иконка группы

Группа: Модераторы
Сообщений: 4898
Регистрация: 27.8.2006
Пользователь №: 18505
Спасибо сказали: 264 раз(а)



Не знает ли кто как форсировать выполнение конкретного inference-правила программы make?

Покажу на примере. Дано inference-правило:
Код
.c.i:
    $(CPP) $(CPPFLAGS) -o $@ $<
Мне требуется его форсировать, то есть заставить выполняться всегда для каждого target'а без оглядки на временной штамп его зависимости. Я пробовал сделать это классическим образом, но «план-перехват результатов не дал»:
Код
ALWAYS=_always

$(ALWAYS):

.c.i:$(ALWAYS)
    $(CPP) $(CPPFLAGS) -o $@ $<
Сейчас я вынужден мириться со следующим workaround'ом в моих makefile-include'ах:
Код
$(IFILES) _dummy:$(ALWAYS)
    $(CPP) $(CPPFLAGS) -o $@ $<
Это некрасиво, а я ценю элегантность и чистоту кода очень высоко. Есть идеи?
 
+Цитировать сообщение
debian
сообщение 17.1.2013, 21:07
Сообщение #223


Постоянный посетитель


Группа: Пользователи
Сообщений: 394
Регистрация: 13.1.2007
Пользователь №: 22600
Спасибо сказали: 42 раз(а)



возможно http://www.gnu.org/software/make/manual/ht...ce-Targets.html
хотя врядли, так говорится о цели в виде несуществующего файла, что явно противоречит задаче

пример взят из "Make BUILD Autotools Управление программными проектами" В.П. Солдатов ISBN 5-9518-0167-2
Код
all:
     make test.o VAR=rebuild

rebuild:

test.o: $(VAR)

Результат:
Код
$ make
make test.o VAR=rebuild
make[1]: Entering directory `/tmp/test'
cc    -c -o test.o test.c
make[1]: Leaving directory `/tmp/test'

$ stat test.o
  File: `test.o'
  Size: 836             Blocks: 8          IO Block: 4096   regular file
Device: 815h/2069d      Inode: 4472855     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  kirill)   Gid: ( 1000/  kirill)
Access: 2013-01-17 22:44:17.000000000 +0400
Modify: 2013-01-17 22:44:17.000000000 +0400
Change: 2013-01-17 22:44:17.000000000 +0400

$ make
make test.o VAR=rebuild
make[1]: Entering directory `/tmp/test'
cc    -c -o test.o test.c
make[1]: Leaving directory `/tmp/test'

$ stat test.o
  File: `test.o'
  Size: 836             Blocks: 8          IO Block: 4096   regular file
Device: 815h/2069d      Inode: 4472855     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  kirill)   Gid: ( 1000/  kirill)
Access: 2013-01-17 22:44:29.000000000 +0400
Modify: 2013-01-17 22:44:29.000000000 +0400
Change: 2013-01-17 22:44:29.000000000 +0400


Сообщение отредактировал debian - 17.1.2013, 21:46
 
+Цитировать сообщение
spy
сообщение 18.1.2013, 0:02
Сообщение #224


Психопат
Иконка группы

Группа: Модераторы
Сообщений: 4898
Регистрация: 27.8.2006
Пользователь №: 18505
Спасибо сказали: 264 раз(а)



debian
Я это уже давным давно попробовал, безрезультатно. Я же написал:
Цитата(spy @ 17.1.2013, 14:03) *
Я пробовал сделать это классическим образом, но «план-перехват результатов не дал»:
Код
ALWAYS=_always

$(ALWAYS):

.c.i:$(ALWAYS)
    $(CPP) $(CPPFLAGS) -o $@ $<


Кстати, еще один вопрос, на этот раз про GNU make: имеющиеся у меня версии не раскрывают $$@ в списке зависимостей, это нормально или все-таки баг?

И последнее: пример Солдатова какой-то дикий. Зачем понадобилось вызывать вложенный make, если можно было сделать проще:
Код
all:test.o

test.o:rebuild
    ...

rebuild:


Update
Нашел решение. В головном makefile'е в корне дерева исходников сделал элементарную банальность:
Код
find $(ROOT)/uts -name \*.\[cS\] -exec touch \{\} \;
 
+Цитировать сообщение
debian
сообщение 18.1.2013, 18:36
Сообщение #225


Постоянный посетитель


Группа: Пользователи
Сообщений: 394
Регистрация: 13.1.2007
Пользователь №: 22600
Спасибо сказали: 42 раз(а)



Цитата(spy @ 18.1.2013, 1:02) *
Кстати, еще один вопрос, на этот раз про GNU make: имеющиеся у меня версии не раскрывают $$@ в списке зависимостей, это нормально или все-таки баг?

Это фича wink.gif GNU Make 3.81 тоже не раскрывает, но можно использовать $^ если я правильно понял вопрос.
 
+Цитировать сообщение
spy
сообщение 18.1.2013, 19:20
Сообщение #226


Психопат
Иконка группы

Группа: Модераторы
Сообщений: 4898
Регистрация: 27.8.2006
Пользователь №: 18505
Спасибо сказали: 264 раз(а)



Приведу пример того, что мне нужно:
Код
$(COMMONTARGETS):$(COMMONPREFIX)$$@ $(ALWAYS)
    ...
COMMONTARGETS = clobber clean rmtargets fluff; COMMONPREFIX содержит что-угодно, не суть важно. Нужно, чтобы каждое из правил в COMMONTARGETS тянуло в качестве зависимости такое же с префиксом COMMONPREFIX, т.е. clobber зависило от $(COMMONPREFIX)clobber, clean от $(COMMONPREFIX)clean, rmtargets от $(COMMONPREFIX)rmtargets и fluff от $(COMMONPREFIX)fluff.

В обычных версиях make, отвечающих стандартам XPG/POSIX (т.е. make из UNIX System V), у меня это правило работает так, как и должно. А вот GNU make дурит.
 
+Цитировать сообщение
debian
сообщение 18.1.2013, 20:34
Сообщение #227


Постоянный посетитель


Группа: Пользователи
Сообщений: 394
Регистрация: 13.1.2007
Пользователь №: 22600
Спасибо сказали: 42 раз(а)



Цитата(spy @ 18.1.2013, 20:20) *
А вот GNU make дурит.

Не уверен, для GNU make стандартным поведением является раскрытие $$A в переменную $A.
Я это использую так:
Код
for i in $(PATCH_DIR)/$(LINUX)-$(LINUX_VER)/*.patch; do\
    patch --directory=$(LINUX) --strip=1 --silent < $$i;\
done

Таким образом $$@ должен раскрываться в $@, но в этом случае этого не происходит или он ракрывается в невидимый символ, вариант с экранированием \$$@ я не рассматриваю, так как, например, $$^ раскрывается в $^.
Но возможно Вам поможет http://www.gnu.org/software/make/manual/ma...ndary-Expansion
Да и в документации http://www.gnu.org/software/make/manual/ma...matic-Variables я не вижу упоминания $$@, так что, эта переменная скорее всего не поддерживается.
 
+Цитировать сообщение
spy
сообщение 18.1.2013, 21:21
Сообщение #228


Психопат
Иконка группы

Группа: Модераторы
Сообщений: 4898
Регистрация: 27.8.2006
Пользователь №: 18505
Спасибо сказали: 264 раз(а)



Цитата(debian @ 18.1.2013, 20:34) *
Не уверен, для GNU make стандартным поведением является раскрытие $$A в переменную $A.
Это в теле правила, а не в списке зависимостей.

Цитата(debian @ 18.1.2013, 20:34) *
Да и в документации http://www.gnu.org/software/make/manual/ma...matic-Variables я не вижу упоминания $$@, так что, эта переменная скорее всего не поддерживается.
$$@ — это обычная переменная $@, только в списке зависимостей, а не в теле правила. Вот выдержка из мана к make'ам из Solaris 10:
Цитата(make(1S))
$@ — The name of the current target. This is the only dynamic macro whose value is strictly determined when used in a dependency list. (In which case it takes the form $$@.)

Однако, вот что я только что прочитал в секции «Rationale» описания make из IEEE Std 1003.1-2008 (он же SUSv4 и POSIX.1-2008):
Цитата(IEEE Std 1003.1-2008)
The System V dynamic dependency feature was not included. It would support:
Код
cat: $$@.c
that would expand to:
Код
cat: cat.c
This feature exists only in the new version of System V make and, while useful, is not in wide usage. This means that macros are expanded twice for prerequisites: once at makefile parse time and once at target update time.
Теперь я понимаю почему GNU make так себя ведет — его писали, имея в виду лишь стандарты POSIX и X/Open, при этом не оглядываясь на UNIX System V, который является моей основной платформой в виде Solaris, AIX, HP-UX и IRIX; придется мне развернуть групповое правило in question в несколько индивидуальных.

Кстати, это наглядный пример того, почему я ненавижу GNU — их идиотская тенденция делать все по-своему и не заботиться о совместимости с SIII/SVR4 и BSD (которых они должны копировать попросту по своей природе, ведь GNU — это свободная копия UNIX), вкупе с распространенностью Linux, портит кровь разработчикам вроде меня, использующим UNIX в качестве основной целевой и хостовой платформы. Чтобы писать портабельное ПО под UNIX (это, как правило, 6 основных систем: Solaris, AIX, HP-UX, IRIX, Tru64 UNIX и UnixWare/OpenServer) особых усилий и кровопролития не требуется — все эти системы замечательно стандартизованы, будучи объединенными SUS'ом и своей SVR4-природой (кроме HP-UX, которая является UNIX System III), различия в базовом API минимальные. Но GNU/Linux... — тут можно остаться без волос! API зачастую не совпадает с UNIX-овым (glibc, интерфейсы ядра, да что угодно), везде понатыканы гнутые «усовершенствования» (_GNU_SOURCE, гори он синим пламенем), опции GCC совершенно не совпадают с опциями CC из UNIX-систем, которые здесь в целом одинаковые (те же -Xa / -Xe или -xarch= поддерживаются и в Forte / Sun Studio, и в HP ANSI C, и в MIPSpro, и в Compaq C), вместо #pragma — __attribute__(()), inline-ассемблер ужасает самим своим существованием, да столько говна развели — можно книгу написать...

Сообщение отредактировал spy - 18.1.2013, 21:34
 
+Цитировать сообщение
GyRT
сообщение 18.1.2013, 23:00
Сообщение #229


Форуман


Группа: Пользователи
Сообщений: 4592
Регистрация: 23.11.2008
Из: Моск. Обл., г. Королев, район Болшево
Пользователь №: 51116
Спасибо сказали: 357 раз(а)



Цитата
API зачастую не совпадает с UNIX-овым (glibc, интерфейсы ядра, да что угодно), везде понатыканы гнутые «усовершенствования» (_GNU_SOURCE, гори он синим пламенем), опции GCC совершенно не совпадают с опциями CC из UNIX-систем, которые здесь в целом одинаковые (те же -Xa / -Xe или -xarch= поддерживаются и в Forte / Sun Studio, и в HP ANSI C, и в MIPSpro, и в Compaq C), вместо #pragma — __attribute__(()), inline-ассемблер ужасает самим своим существованием, да столько говна развели — можно книгу написать...

Use RH? не? А как компилер ICC на x86 и clang на остальном (хотя пока не везде еще). В чем проблема?

Сообщение отредактировал GyRT - 18.1.2013, 23:00


--------------------
| Ник в DC++: St.Server or [CiNet]Gyrt | icq: 370984297 (антиспамбот OFF) | ники на форумах: GyRT or mariner |
Ресурсы: dchub://dc.klan-hub.ru - [K.lan]Hub

Цитата(о копирайтах)
>адоба правильносебя защищает, она создала технологию и имеет право ее защищать.
Я создал технологию, которая позволяет засунуть тебе в анус сучковатое полено. Я имею право ее защишать, то есть привязать тебя... Эй, эй, куда побежал?..
 
+Цитировать сообщение
spy
сообщение 18.1.2013, 23:02
Сообщение #230


Психопат
Иконка группы

Группа: Модераторы
Сообщений: 4898
Регистрация: 27.8.2006
Пользователь №: 18505
Спасибо сказали: 264 раз(а)



ICC я использую. А проблема в том, что я не привязываюсь к конкретному компилятору и поддерживаю максимум из тех, к каким имею доступ. Коммерческие компиляторы для RISC-платформ генерируют более качественный код, чем GCC или LLVM.
 
+Цитировать сообщение
GyRT
сообщение 18.1.2013, 23:04
Сообщение #231


Форуман


Группа: Пользователи
Сообщений: 4592
Регистрация: 23.11.2008
Из: Моск. Обл., г. Королев, район Болшево
Пользователь №: 51116
Спасибо сказали: 357 раз(а)



Не проверял, т.к. из Risc только RaspberryPi есть. А вот на счет стандартов - чем тебя RHEL не устроил, который вполне себе SUS?


--------------------
| Ник в DC++: St.Server or [CiNet]Gyrt | icq: 370984297 (антиспамбот OFF) | ники на форумах: GyRT or mariner |
Ресурсы: dchub://dc.klan-hub.ru - [K.lan]Hub

Цитата(о копирайтах)
>адоба правильносебя защищает, она создала технологию и имеет право ее защищать.
Я создал технологию, которая позволяет засунуть тебе в анус сучковатое полено. Я имею право ее защишать, то есть привязать тебя... Эй, эй, куда побежал?..
 
+Цитировать сообщение
spy
сообщение 18.1.2013, 23:09
Сообщение #232


Психопат
Иконка группы

Группа: Модераторы
Сообщений: 4898
Регистрация: 27.8.2006
Пользователь №: 18505
Спасибо сказали: 264 раз(а)



Вопрос не только в соответствии стандарту, но и в том, что GNU любят делать все по-своему и привносить нестандартный функционал. Популярность GNU/Linux делает этот функционал общеупотребимым и заставляет менее просвещенных людей думать, что раз оно так в Linux, то и везде аналогично. В результате чего портировать множество софта на ту же IRIX, не таща в нее glibc, весьма затруднительно.

Сообщение отредактировал spy - 18.1.2013, 23:11
 
+Цитировать сообщение
NewUse
сообщение 26.3.2013, 19:16
Сообщение #233


Форуман


Группа: Пользователи
Сообщений: 11933
Регистрация: 25.9.2008
Пользователь №: 46679
Спасибо сказали: 1046 раз(а)



Народ, регулярные выражения POSIX ERE случайно никто не копал?
Как сделать отрицание слова целиком? что то типа !alpha ?

\B(alpha) не работает sad.gif


--------------------
Модератор тоже человек, способный ошибаться.
Всё, что я пишу - IMHO, если не написано обратное.
Флуд и флейм портят настроение модераторам, а пользователям рейтинг.
 
+Цитировать сообщение
debian
сообщение 27.8.2013, 19:11
Сообщение #234


Постоянный посетитель


Группа: Пользователи
Сообщений: 394
Регистрация: 13.1.2007
Пользователь №: 22600
Спасибо сказали: 42 раз(а)



Доброго дня!
Кто-нибудь использовал в работе SCTP (http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol), каковы впечатления?
Насколько легко его можно использовал в гетерогенной сети Linux - Windows?
 
+Цитировать сообщение
spy
сообщение 7.10.2013, 8:57
Сообщение #235


Психопат
Иконка группы

Группа: Модераторы
Сообщений: 4898
Регистрация: 27.8.2006
Пользователь №: 18505
Спасибо сказали: 264 раз(а)



Я использовал SCTP в stateful-режиме, как TCP, но исключительно между Линуксами и Solaris, никакой Винды (я вообще не слышал, чтобы Винда его поддерживала.) SCTP это хорошо, но объективной потребности в нем нет, комбинации TCP/UDP/RDS хватает. Ведь мало иметь его поддержку на оконечных машинах — в большинстве случаев использования транспортного протокола в том же Интернете необходимо иметь его поддержку NAT-ами оконечных роутеров тракта (с одной стороны прямой NAT, а с другой NAT traversal, т.е. PAT), т.к. сейчас за NAT-ами сидит очень много абонентов. К тому же я не поручусь, что его механизмы flow control так же хорошо вылизаны, как у TCP в его различных вариантах.
 
+Цитировать сообщение
debian
сообщение 7.10.2013, 21:10
Сообщение #236


Постоянный посетитель


Группа: Пользователи
Сообщений: 394
Регистрация: 13.1.2007
Пользователь №: 22600
Спасибо сказали: 42 раз(а)



Цитата(spy @ 7.10.2013, 9:57) *
я вообще не слышал, чтобы Винда его поддерживала

не знаю насколько работоспособно, но http://www.bluestop.org/SctpDrv/

Я правильно понял, что при использовании SCTP возможны проблемы с NAT?
Собсвенно, мне надо обеспечить управление рядом железок которые находятся за NAT, выходят в сеть через 3G/LTE модемы, и SCTP в данном случае меня привлекает возможность установить связь с несколькими "серверами" одновременно.
Пока начал реализовывать на основе TCP, как более традиционного.
 
+Цитировать сообщение
spy
сообщение 9.10.2013, 1:53
Сообщение #237


Психопат
Иконка группы

Группа: Модераторы
Сообщений: 4898
Регистрация: 27.8.2006
Пользователь №: 18505
Спасибо сказали: 264 раз(а)



Цитата(debian @ 7.10.2013, 21:10) *
Я правильно понял, что при использовании SCTP возможны проблемы с NAT?
Да, ведь для работы SCTP через типичный NAT (SOHO-роутер или NAT на уровне провайдера) необходимо, чтобы этот NAT имел поддержку этого протокола и строил таблицу динамических трансляций, в точности как для TCP и UDP. Ведь NAT с перегрузкой (overload NAT — частный случай, когда целый диапазон внутренних IP-адресов транслируется в один внешний, как это делается сплошь и рядом на SOHO-роутерах и у провайдеров, выдающих абонентам «серые» IP-адреса) различает абонентов-получателей идущих в обратную сторону IP-пакетов по информации из вышестоящего (транспортного) протокола, а именно по номерам портов TCP и UDP, что требует знания устройства протокола (формата его датаграммы.) В случае SCTP его поддержка есть лишь на промышленном оборудовании, а в SOHO — только если в составе альтернативных прошивок.
 
+Цитировать сообщение

12 страниц V  « < 10 11 12
Ответить в данную темуНачать новую тему
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0



© 2005—2016 ООО «Нэт Бай Нэт Холдинг»,
Все права защищены.
Правила пользования ресурсами