Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4, opennews (?), 24-Окт-17, (0) [смотреть все] Это они его переписывают или хотят 3-ю версию довести до кондиции и сделать ЛТС , Жта5 (?), 00:19 , 24-Окт-17, (1) +7 // Они хотят довести до LTS веток каждый мажорный релиз, причем с меньшими различия, COBA (?), 00:24 , 24-Окт-17, (3) +4 Нет Это отдельная, просто у них традиция приписывать версии выше примерно 3 90 , marks (?), 00:28 , 24-Окт-17, (5) +4 // Отдельная - в смысле переделывают Меня внутренности интересуют, а в циферки каж, Жта5 (?), 00:59 , 24-Окт-17, (12) // Ты новость читал , upyr (?), 11:00 , 24-Окт-17, (47) Читал и что Намекаешь, что там не описаны мажорные изменения и их не так много , жта5 (?), 19:53 , 24-Окт-17, (126) С полгода назад тут новость пробегала о новой нумерации версий Суть в том, что , Аноним (-), 00:30 , 24-Окт-17, (7) +1 // Давайте похлопаем этому анониму за талант в ЛПП и перекручивании фактов , Аноним (-), 19:04 , 24-Окт-17, (118) // У тебя явно никогда не ломались темы виджеты в GTK3 Давай похлопаем тебе, а , Аноним (-), 04:24 , 25-Окт-17, (139) Знаете товарищи, я пытался привыкнуть к гному, но мириться с его тормозами с, Аноним (-), 00:21 , 24-Окт-17, (2) +10 // Казалось бы при чём тут Гном в новости про новый тулкит, но анонимные аналитики , marks (?), 00:25 , 24-Окт-17, (4) // Да-да, отображение GtkLabel через полурабочий тормозной 3D-драйвер конечно не , Аноним (-), 00:32 , 24-Окт-17, (8) –6 // Зачем вам полурабочий тормозной 3D-драйвер , Аноним (-), 08:47 , 24-Окт-17, (23) +4 Судя по api рисовать блур, затухание и блендинг Или возложить на процессор , оно ним (?), 13:39 , 24-Окт-17, (78) Не рисовать их вообще 8212 не вариант , Аноним (-), 19:09 , 24-Окт-17, (119) +3 где gnome-shell, где gtk, и где полурабочий 3d-драйвер , pripolz (?), 14:05 , 24-Окт-17, (82) –1 Я бы ответил где, в рифму, но это не печатаемо Так что, где-то ниже Вы попали , Ыйя (?), 20:23 , 24-Окт-17, (128) Знаю это чувство Мне даже нравятся интерфейсные решения, я понимаю логику, кото, Наноним (?), 04:50 , 24-Окт-17, (16) +3 // Если ты понимаешь логику гном, скажи мне для чего часы в верхней панели по центр, Аноним (-), 07:46 , 24-Окт-17, (20) +12 // Для того чтобы смотреть времяТут три момента сенсорные экраны, CSD и просто удо, Аноним (-), 10:31 , 24-Окт-17, (38) –4 Смотреть время Б ть, это не смотреть, это пялиться на время Мух от котлет де, кверти (ok), 11:30 , 24-Окт-17, (57) +6 На ноутбуках с сенсорным экраном - удобство В win для этого же сделали плитки и, llolik (ok), 12:24 , 24-Окт-17, (64) –2 Ноутбуки с сенсорными экранами и удобство - это два разных мира Ах вон оно что, , кверти (ok), 13:16 , 24-Окт-17, (73) +6 Они не на винду равняются, а видят что, как бы нам не хотелось обратного, движет, llolik (ok), 13:28 , 24-Окт-17, (74) Как в ваши головы это вообще все заходит Откуда этот бред Ты решил, что все по, кверти (ok), 13:56 , 24-Окт-17, (81) +2 А вы с современными школьниками младших классов общаться пробовали Они уже предп, Stax (ok), 15:26 , 24-Окт-17, (95) когда работа выходит на уровень чуть сложнее вэб сёрфинга и игрулек, то сразу на, кверти (ok), 15:52 , 24-Окт-17, (102) +3 гнумтри разработан с учётом в том числе киосков и касс и нет никакой причины иск, номия (?), 11:06 , 25-Окт-17, (146) –1 Одни из рэдмонда так уже считали Где они на рынке мобильных устройств все мы зн, кверти (ok), 11:39 , 25-Окт-17, (148) +3 а какое удобство в маленьких кнопках компьютерами таки пользуются не только мас, номия (?), 10:52 , 25-Окт-17, (145) +1 Для инвалидов отдельные средства есть , anonymous (??), 13:38 , 25-Окт-17, (155) +2 Ты живешь на другой планете и планшеты туда не завезли Ребят, соберите несчастн, Аноним (-), 18:42 , 25-Окт-17, (158) –1 У меня не сенсорный экран, а монитор 24 И дома и на работе На арботе два Нах, adolfus (ok), 16:15 , 24-Окт-17, (105) +1 Не знаю, кому как, а мне так удобнее, чем высматривать в свалке в правом углу , marks (?), 11:54 , 24-Окт-17, (58) +1 А мне казалось, что размер элементов должен зависеть от физических размеров экра, Аноним (-), 13:09 , 24-Окт-17, (72) +2 Так, да не так Когда мы говорим об примерно одного размера физических экранах н, Stax (ok), 15:30 , 24-Окт-17, (97) +1 Таки всё так Ну вот тогда должен быть класс устройств А то тут пишут про Та, Аноним (-), 15:39 , 24-Окт-17, (99) Расстояние от глаз для монитора и планшета смартфона не сильно отличается, где-т, Аноним (-), 11:53 , 25-Окт-17, (149) и почему они делаю такие большие заголовки у приложений Ну в основном потому, , Аноним (-), 12:42 , 24-Окт-17, (68) Вообще-то, все это должно настраиваться Если я работаю в полноэкранном режиме, , adolfus (ok), 16:23 , 24-Окт-17, (106) и оно таки настраивается но пока через правку конфигов и твиктулзы есть причин, номия (?), 11:14 , 25-Окт-17, (147) Единственное, чего я не понимаю в логике гнома 8211 там не предусмотрено реше, Наноним (?), 14:41 , 24-Окт-17, (90) Эм Да вроде всегда был Стандартный механизм XDG там используется нынче, как да, Stax (ok), 15:35 , 24-Окт-17, (98) Третий гном точно не умеет f11 Он вобще не может ни спозиционировать окно, ни з, adolfus (ok), 16:27 , 24-Окт-17, (107) Тогда почему, уведомления показываются маленьким круглешком почему не мигает, т, DenisSh (?), 21:46 , 25-Окт-17, (163) Поддерживаю вас Тоже вкатили различные решения и элементы ДЕ, но тормоза Как, Аноним (-), 05:18 , 24-Окт-17, (17) +2 Купил мак, понял что гномосеки не только не поняли основую идею но еще и изврати, username (??), 09:50 , 24-Окт-17, (30) +8 // Да в Маке тоже сомнительных решений полно Почему, блин, просто нельзя развернут, Другой аноним (?), 10:54 , 24-Окт-17, (44) +1 // Как же я вас понимаю А так всё просто пиппл и так хавает, выстаивает многочасов, Анонимен (?), 11:06 , 24-Окт-17, (49) Может лучше наконец в 2017 году купить видеокарту с поддержкой 3D-ускорения , Аноним (-), 10:25 , 24-Окт-17, (37) –7 // Конечно Давайте всем офисным сотрудникам понаставим мощных видюх, по 16ГБ памят, Другой аноним (?), 10:57 , 24-Окт-17, (45) +12 // Какой бред ЧТо надо сделать чтобы гном начал тормозить на более менее современн, Аноним (-), 11:03 , 24-Окт-17, (48) –6 Пользователь не должен замечать работы DE Если Ваше окружение жрет ресурсы, а т, Другой аноним (?), 11:20 , 24-Окт-17, (56) +2 Да-да, у вас в конторе целероны с ХП именно поэтому, а не по причине ни-ще-бродс, Аноним (-), 12:02 , 24-Окт-17, (59) –2 Мне всегда нравилась эта позиция, особенно распространённая среди геймеров, что , Ordu (ok), 12:33 , 24-Окт-17, (67) +5 Обратная крайность тоже вызывает большие сомнения в психическом здоровье страдаю, Аноним (-), 15:48 , 24-Окт-17, (100) Крайности всегда странны Но ты упускаешь из вида один нюанс если тебе хочется , Ordu (ok), 17:07 , 24-Окт-17, (111) +2 Вообще не понимаю что такое апгрейды и зачем они нужны Это какой-то упоризм -, Аноним (-), 15:30 , 25-Окт-17, (156) Я описывал выше два примера стратегий поддержания железа в актуальном состоянии , Ordu (ok), 17:41 , 25-Окт-17, (157) +1 Celeron ов и XP к счастью нет, но Core 2 Duo кое-где остались Только что в этом, Другой аноним (?), 12:59 , 24-Окт-17, (71) Нет, это когда ты имея возможность купить нормальный автомобиль среднего класса , Аноним (-), 15:51 , 24-Окт-17, (101) Ладно, глупости все это Мы разговариваем про предприятие и бизнес, где под любо, Другой аноним (?), 16:05 , 24-Окт-17, (103) Ога Это когда не имея средств и надобности вместо ржавой шохи покупают бэху и и, Ыйя (?), 20:49 , 24-Окт-17, (131) Я просто поставил гном на планшет, и получил лагодром Acer w500 И да драйвера п, Fodrice (?), 15:06 , 24-Окт-17, (92) И да, лучше б они отдельную екранную клавивтуру завезли То что есть ща на линуц, Fodrice (?), 15:09 , 24-Окт-17, (93) Зачем интерфейсу такая карта Пирдеть и свистеть , adolfus (ok), 16:29 , 24-Окт-17, (108) И к чему в здесь об этом Проблема по-вашему в GTK или что вы хотели сказать , Аноним (-), 18:03 , 24-Окт-17, (114) Ну всё, теперь заживём Это именно то, что не хватало , Аноним (-), 00:28 , 24-Окт-17, (6) +3 // https keddr com wp-content uploads 2015 03 Emoji-Keyboard jpg, VINRARUS (ok), 00:57 , 24-Окт-17, (9) +3 // А вот так и надо сделать, общаться небольшими ребусами будем Исчезнет недопоним, Аноним (-), 08:14 , 24-Окт-17, (22) +1 Шо ж ты делаешь, ирод Как мне теперь развидеть это , Аноним (-), 10:39 , 24-Окт-17, (40) +1 // Отак http static nix ru autocatalog keyboards_sven 160817_2245_draft jpg , VINRARUS (ok), 17:19 , 24-Окт-17, (112) Не практично Вообще бы классно было бы иметь на клавиатуре вместо NumPad а Emoji, iPony (?), 12:27 , 24-Окт-17, (65) +1 // Ну так настро А, у тебя мак Сочувствую , Аноним (-), 13:34 , 24-Окт-17, (76) +1 Чего сочувствовать В macOS с Emoji всё в порядке, ну так речь о другом Emoji оч, iPony (?), 10:15 , 25-Окт-17, (144) Это, типа, бусы, которыми решено привлекать папуасов , adolfus (ok), 16:30 , 24-Окт-17, (109) А как там бинарная совместимость Приложение времен ASPLinux 10 запустится , kulais (?), 01:39 , 24-Окт-17, (13) // запустится, если рядом положишь gtk нужной версии - , нежданчик (?), 04:47 , 24-Окт-17, (14) +1 А зачем в опенсорсе бинарная совместимость Важна совместимость на уровне исходн, Аноним (-), 09:56 , 24-Окт-17, (31) +1 // Ну собери исподник 10 и более летней давности современным gcc С - совместимость, Аноним (-), 10:40 , 24-Окт-17, (41) +1 // А в современном GCC изчезла опция -std c89 99 , Аноним (-), 10:59 , 24-Окт-17, (46) +1 Ты никогда не видел, сколько в сорцах любого дистра патчей с характерными назван, Аноним (-), 16:09 , 24-Окт-17, (104) –1 Как зачем Тебе не приходилось несколько часов пересобирать грядку пакетов после, Ordu (ok), 12:28 , 24-Окт-17, (66) +2 // Приходилосьemerge preserved-rebuild , Аноним (-), 18:49 , 24-Окт-17, (116) Если приходилось, то чего я объясняю тогда, ты и сам понимаешь , Ordu (ok), 19:22 , 24-Окт-17, (122) И что такое пару чаcов по сравнению с пересборкой всего world, Аноним (-), 18:55 , 24-Окт-17, (117) Не все любят пересобирать мир каждую неделю , Аноним (-), 19:18 , 24-Окт-17, (120) на gma3150 gnome-shell не юзабелен, как и юнити ток lxde, xfce, e17 и дальше т, Аноним (-), 07:27 , 24-Окт-17, (19) +1 // DIceWM же этому господину, ну или голый Open или другой Box, IB (?), 09:42 , 24-Окт-17, (29) а у Вас есть сборочки с e17 и e21 , Аноним (-), 10:00 , 24-Окт-17, (34) Человек перечислял DE, ты ему советуешь WM Миш, вторник уже, завязывай бухать, Sluggard (ok), 10:34 , 24-Окт-17, (39) +2 на gma500 проблема в основном в том, что dri,libva,mesa и прочее завязаны на ста, pripolz (?), 14:19 , 24-Окт-17, (84) Крестик на тулките большой чтобы точно попасть в него , Аноним (-), 09:22 , 24-Окт-17, (26) +2 Эх, молодёжь По описанию Мезона да и других новых систем сборки, типа Шейк, Аноним (-), 09:30 , 24-Окт-17, (27) +5 // А ты побовал Meson шикарен , upyr (?), 11:13 , 24-Окт-17, (53) –2 Так и Meson не собирает, собирает Ninja Ninja пошустрей make будет, хотя КМК и , llolik (ok), 12:18 , 24-Окт-17, (62) +1 // Наверно, это придётся повторять всё чаще m4 или Перл не нужны во время конфигур, Аноним (-), 20:19 , 24-Окт-17, (127) // Зависит от радиуса кривизны рук разработчика Некоторые ухитряются писать bash-o, Аноним (-), 22:26 , 24-Окт-17, (134) Это вы ещё Gradle не видели Обслуживающий сборку код - очевидно ради самого , iZEN (ok), 22:51 , 24-Окт-17, (136) По тормознутости, сложности и ненадёжности Я верю, что в этом никто и никогда н, Аноним (-), 13:36 , 24-Окт-17, (77) // Дело в том, что я часто вижу такое конфигугирование if platform system L, Аноним (-), 20:25 , 24-Окт-17, (129) // Зачем для проверки наличия файла запускать компиляцию А autocrap таки её запуст, Аноним (-), 22:39 , 24-Окт-17, (135) Вот-вот Затем, что только компилятор знает, где foo bar h лежит Затем, что ф, Аноним (-), 09:14 , 25-Окт-17, (141) +1 Откуда он это может знать, если не из опций, которые ему передаёт система сборки, Аноним (-), 11:59 , 25-Окт-17, (150) Вот это смешно было Между прочим, я уважаю cmake, и пишу на нём аккуратно, но , Аноним (-), 09:21 , 25-Окт-17, (142) Поделись, где ты увидел про лопату Я б тоже поржал Что не так с глобальным conf, Аноним (-), 12:18 , 25-Окт-17, (152) https www opennet ru opennews art shtml num 47031Здесь что-то не чисто Сборка, Аноним (-), 09:34 , 24-Окт-17, (28) +2   // В случае с autocrap 8212 это ещё и прогон 100500 тестовых компиляций для пров, Аноним (-), 09:57 , 24-Окт-17, (32)   // но автотесты же не должны входить во время сборки , Аноним (-), 10:42 , 24-Окт-17, (42) +2   // Должны или не должны Какая разница, если они входят Ну, ты попробуй собрать , Ordu (ok), 12:21 , 24-Окт-17, (63)   Во время сборки не проходят Проходят во время конфигурации Тебе configure , Аноним (-), 13:41 , 24-Окт-17, (79)   Давайте еще говорить, что после перехода с gzip на xz время сборки уменьшилось, , Аноним (-), 10:49 , 24-Окт-17, (43) –1   В новости ошибка - там замеры были не на mesa, а на libdrm Библиотека libdrm не, Mihail Zenkov (ok), 14:07 , 24-Окт-17, (83)   сравнивают скорее всего meson buildir cd builddir ninjac configure m, dhamp (?), 18:28 , 24-Окт-17, (115)   // Просто для примера сборка одного проекта cmake ninja 1917 45s user 133 06s sys, dhamp (?), 20:45 , 24-Окт-17, (130) +1   Нет Если они и хитрят, то с выбором железа для сборки GTK сваян на C Компилято, Ordu (ok), 20:51 , 24-Окт-17, (132) +2   // Зависит от проекта Если в проекте собираются одновременно несколько подпроектов, Mihail Zenkov (ok), 09:55 , 25-Окт-17, (143) +1   И это работает Ну, в том смысле, что между генерацией config cache и следующим , Ordu (ok), 19:35 , 25-Окт-17, (159)   Собираем всю систему и попутно собираем все config cache Генерируем config site, Mihail Zenkov (ok), 21:44 , 25-Окт-17, (162)   Поддержание своей системы сборки будет требовать гораздо больше времени Все эти, Ordu (ok), 03:05 , 26-Окт-17, (164)   На самом деле - не факт Все зависит от задач Если вы постоянно ежедневно мен, Mihail Zenkov (ok), 10:34 , 26-Окт-17, (165)   Во-первых, у configure есть кеш, см configure --help во-вторых, даже если , Аноним (-), 12:04 , 25-Окт-17, (151)   Если я вожусь с командной строкой, то тормоза вносимые моими кривыми пальчиками , Ordu (ok), 20:14 , 25-Окт-17, (161)   Нескольких 8212 это двух-трёх Потом всё равно переписывать , Аноним (-), 10:00 , 24-Окт-17, (33) +2 А патриарх СПО это одобрил Или Gtk 4 не является частью проекта GNU , Аноним (-), 10:02 , 24-Окт-17, (35) // Красношапка одобрила Кто платит, тот и одобряет Хотя вон и в GNU awk запилили c, Аноним (-), 12:52 , 24-Окт-17, (69) Какая великая сила денег заставляет клепать такие жуткие дефолтовые темы , Аноним (-), 10:24 , 24-Окт-17, (36) +1 // Наверное, полное отсутствие этой силы , Аноним (-), 11:07 , 24-Окт-17, (50) // А вот фиг, без денег школьники на гномелуке клепают красивые темы, а дефолтом ка, Аноним (-), 12:55 , 24-Окт-17, (70) Кстати, да Темы Gtk3 - это какой-то туманный образ нормальных мыслеформ после п, iZEN (ok), 11:12 , 24-Окт-17, (52) // Так попробуй на трезвую голову осмыслить , upyr (?), 11:16 , 24-Окт-17, (54) // Ни разу не видел его трезвым с 2008-го , Аноним (-), 12:11 , 24-Окт-17, (61) +1 Из-за идиотских скроллбаров и микроскопических подвижных границ разделения панел, iZEN (ok), 11:10 , 24-Окт-17, (51) +4 // Так не ной здесь, а напиши в багтрекер Caja , upyr (?), 11:18 , 24-Окт-17, (55) +1 // Тут общая концепция в тулките такая, а не конкретный файл-менеджер появляющиеся, iZEN (ok), 14:26 , 24-Окт-17, (86) +2 // В Nautilus почему-то такой проблемы нет , Аноним (-), 17:23 , 24-Окт-17, (113) наверняка это можно настроить через css стили или ещё как А вот, как в генте с, all_glory_to_the_hypnotoad (ok), 21:21 , 24-Окт-17, (133) +1 долгое время пытаюсь понять Кто-то вообще пишет что-то на GTK в рабочее время , pripolz (?), 14:23 , 24-Окт-17, (85) +1 // Да Сотрудники RedHat , Аноним (-), 19:22 , 24-Окт-17, (123) –1 Да Ниже то, что смог вспомнить Из минусов 1 Нет обработки ошибок выделения пам, Аноним (-), 19:36 , 24-Окт-17, (124) +4 // ЭЭ они же просто указатели всегда, разве нет , pripolz (?), 12:37 , 25-Окт-17, (153) // Раскройте макрос GTK_LABEL label , будете удивлены Там встроено самотестиров, Аноним (-), 19:38 , 25-Окт-17, (160) +1 Надеялся, что meson будет параллельно работать Облом 2017-ый год Элементарнейш, Андрей (??), 23:02 , 24-Окт-17, (137) Означает ли это что анимации будет отрсовывать не проц а видеокарта и гном перес, Аноним (-), 13:04 , 25-Окт-17, (154) 1,2,6,13,19,26,27,28,33,35,36,51,85,137,154

Сообщения

[Сортировка по времени | RSS]

28. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	+2 +/–
Сообщение от Аноним (-), 24-Окт-17, 09:34
https://www.opennet.ru/opennews/art.shtml?num=47031 > По сравнению с Autotools время сборки GTK+ сократилось в три раза. На пути к переходу на Meson также находится проект Mesa - сборка Mesa при помощи Meson оказалась в 4 раза быстрее при первом запуске и в 10 раз быстрее при повторном. Здесь что-то не чисто. Сборка - это вызовы компилятора/компоновщика, время не зависит от "системы сборки".
Ответить | Правка | Наверх | Cообщить модератору

	32. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	+/–
	Сообщение от Аноним (-), 24-Окт-17, 09:57
	В случае с autocrap — это ещё и прогон 100500 тестовых компиляций для проверки наличия тех или иных либ, функций, заголовков и т. п.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	+2 +/–
	Сообщение от Аноним (-), 24-Окт-17, 10:42
	но автотесты же не должны входить во время сборки...
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	+/–
	Сообщение от Ordu (ok), 24-Окт-17, 12:21
	Должны или не должны... Какая разница, если они входят? Ну, ты попробуй собрать gtk без прогона автотестов и увидишь сам.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	+/–
	Сообщение от Аноним (-), 24-Окт-17, 13:41
	> но автотесты же не должны входить во время сборки... Во время сборки не проходят. Проходят во время конфигурации. Тебе ./configure && make запускать доводилось? Загляни как-нибудь в config.log и ужаснись.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	43. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	–1 +/–
	Сообщение от Аноним (-), 24-Окт-17, 10:49
	Давайте еще говорить, что после перехода с gzip на xz время сборки уменьшилось, так как теперь загрузка быстрее.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	83. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	+/–
	Сообщение от Mihail Zenkov (ok), 24-Окт-17, 14:07
	> Здесь что-то не чисто. В новости ошибка - там замеры были не на mesa, а на libdrm. Библиотека libdrm небольшая и запуск configure идет дольше сборки. Для больших библиотек типа mesa выигрыш будет максимум 10% (и то, только если сам meson окажется быстрее configure в десять раз).
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	115. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	+/–
	Сообщение от dhamp (?), 24-Окт-17, 18:28
	сравнивают скорее всего $meson buildir && cd builddir && ninja c $./configure && make по сути сравнение make -j1 vs ninja -j$(nproc) Сравнение времени выполнения meson и configure в большистве случаев бесполезно, т.к. сборка занимает по времени много больше. "Корректность" сравнения зашкаливает.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	130. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	+1 +/–
	Сообщение от dhamp (?), 24-Окт-17, 20:45
	Просто для примера сборка одного проекта. cmake + ninja 1917.45s user 133.06s system 1013% cpu 3:22.26 total cmake + make -j$(nproc) 1890.67s user 141.66s system 941% cpu 3:35.91 total Профит сомнителен.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	+2 +/–
	Сообщение от Ordu (ok), 24-Окт-17, 20:51
	> сравнивают скорее всего Нет. Если они и хитрят, то с выбором железа для сборки. > сборка занимает по времени много больше. GTK сваян на C. Компиляторы C просто реактивные, по сравнению с некоторыми. При этом, в отличие от configure, процесс собственно компиляции отлично ускоряется увеличением числа ядер. А вот ./configure будет тормозить на 8-ядерном процессоре ровно так же, как он тормозил на одноядерном. Если в проекте несколько скриптов ./configure, то каждый из них будет тормозить, и делать они это будут по-очереди, занимая ровно одно ядро. Ещё интереснее, когда distcc используешь, чтобы собирать свою генту в офисе, где удалось тихим вечерком два десятка офисных компов в сборочный кластер собрать, чтобы по-бырому раскатать дженту на не очень шустром ноуте. Там этот configure начинает откровенно выбешивать. Вообще складывается ощущение, что вся сборка состоит из бесконечных вызовов ./configure и бесконечных проверок того, что char занимает 1 байт, "может что изменилось с предыдущего раза и char подрос?". Весь этот вывод configure уже заучен наизусть, я его сам могу на клавиатуре набрать с закрытыми глазами, ан нет, автотулзы продолжают долбить в одну и ту же точку. А, и да, я отмечу, что так бесили они меня более десяти лет назад, и те два десятка офисных компов были селерончиками в которых, если мне память не изменяет, стояли смешные 256Mb оперативки. Что будет сейчас, если это не селерончики, а какие-нибудь двух-четырёх ядерные монстры, я вообще с трудом представляю. Секунд десять думает emerge, потом ещё тридцать секунд configure, после чего пять секунд компиляции, две секунды линковки, и ещё секунд десять на emerge. Что-нибудь в этом стиле. Реально погреться такому кластеру удастся только на всяких там файрфоксах да опенофисах.
	Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

	143. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	+1 +/–
	Сообщение от Mihail Zenkov (ok), 25-Окт-17, 09:55
	> Если в проекте > несколько скриптов ./configure, то каждый из них будет тормозить, и делать > они это будут по-очереди, занимая ровно одно ядро. Зависит от проекта. Если в проекте собираются одновременно несколько подпроектов/библиотек, то не кто не запрещает во время компиляции одного запустить configure у другого. AFAIK gcc так и делает. > бесконечных проверок того, что char > занимает 1 байт, "может что изменилось с предыдущего раза и char > подрос?". Весь этот вывод configure уже заучен наизусть, я его сам > могу на клавиатуре набрать с закрытыми глазами, ан нет, автотулзы продолжают > долбить в одну и ту же точку. Учить нужно не вывод, а маны :) Я сам так много лет смотрел и думал - сколько можно проверять char? Наконец залез в доки и нашел:     https://www.gnu.org/software/automake/manual/html_node/confi...     https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/a...     https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/a... Сделал программу, которая собирает config.cache после сборки. Потом запускаю вторую программу, которая анализирует все имеющиеся config.cache и создает config.site, в который попадают только те переменные, которые имеют одно и тоже значение во всех config.cache. Тестировал на lfs, но большого выигрыша не увидел (собираю на четырех ядрах). Возможно на blfs выигрыш будут более значимым (особенно на Xorg - там реально в раза два быстрее должно получится).
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	+/–
	Сообщение от Ordu (ok), 25-Окт-17, 19:35
	> Сделал программу, которая собирает config.cache после сборки. Потом запускаю вторую программу, которая анализирует все имеющиеся config.cache и создает config.site, в который попадают только те переменные, которые имеют одно и тоже значение во всех config.cache. И это работает? Ну, в том смысле, что между генерацией config.cache и следующим запуском ./configure произойдёт установка пакета, которая вообще-то может инвалидировать какие-то переменные в этом config.cache. Кстати да, я даже конкретный сценарий могу предложить. Ставим софтину с опциональной зависимостью от gtk. Её configure проверяет наличие gtk, не находит его в системе, вносит в config.cache запись о том, что gtk в системе нет. Ставим gtk. А теперь ставим софтину с жёсткой зависимостью от gtk. Теперь configure заглядывает в config.site, находит, что gtk в системе нету, и отказывается генерировать Makefile. Другое дело, что может если собрать переменные, которые стопудов никогда не меняются (скажем, относящиеся к проверкам libc и cc) и один раз их сложить в config.site... Кроме того, тут встаёт проблема, что если я в процессе пересборки системы занимаюсь вознёй с этими кешами, то я встраиваю в процесс пересборки ещё более тормозной этап, нежели ./configure -- себя. Таким образом, чтобы с этого получить хоть какой-нибудь бонус по скорости, надо это всё автоматизировать, а для этого надо лезть в портажи и перелопачивать eclass'ы. В идеальном случае будет достаточно изменить один eclass, но я не верю в идеальные случаи. Скорее всего придётся поменять несколько eclass'ов, и ещё процентов 10 ебилдов всё равно будут всё делать по-своему. То есть, здравый баланс между оптимизмом и пессимизмом предсказывает часов 40-80 на перепиливание портажей. _Моих_ 40-80 часов, а не сборочного кластера. Причём с неопределённым результатом: может быть не удастся сделать так, чтобы config.site не создавал бы помех, и не приходилось бы ещё и вручную периодически вмешиваться, чтобы сборка продолжалась бы.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	+/–
	Сообщение от Mihail Zenkov (ok), 25-Окт-17, 21:44
	>> Сделал программу, которая собирает config.cache после сборки. Потом запускаю вторую программу, которая анализирует все имеющиеся config.cache и создает config.site, в который попадают только те переменные, которые имеют одно и тоже значение во всех config.cache. > И это работает? Собираем всю систему и попутно собираем все config.cache. Генерируем config.site. Повторная сборка системы будет гораздо быстрее. Но да, все это можно легко сломать. > Другое дело, что может если собрать переменные, которые стопудов никогда не меняются > (скажем, относящиеся к проверкам libc и cc) и один раз их > сложить в config.site... Таких переменных не так уж и много. Выигрыш будет не большой. Тут нужна методика четко позволяющая отделить переменные и константы для конкретно вашей системы. Есть у меня мысль попробовать исключить все переменные, которые используются менее трех раз. Но в итоге и встает вопрос, а стоит ли оно того? >  Таким образом, чтобы с этого получить хоть какой-нибудь бонус по скорости, надо это всё автоматизировать, а для этого надо лезть в портажи и перелопачивать eclass'ы. У меня своя система сборки. На все правки, включая написание программ для сборки и обработки config.cache ушло 3-4 часа. Но как я сказал, выигрыш не велик, а вероятность получить проблемы после очередных изменений в системе далеко не нулевая. С другой стороны, если появилась проблема - отключаем config.site и собираем как обычно. Вроде ничего сложного. Вообще нужно поработать с этим какое-то время, чтобы набрать некоторую статистику по отказам.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	+/–
	Сообщение от Ordu (ok), 26-Окт-17, 03:05
	> У меня своя система сборки. На все правки, включая написание программ для > сборки и обработки config.cache ушло 3-4 часа. Поддержание своей системы сборки будет требовать гораздо больше времени. Все эти задачи связанные с обсчётом депендансов, выкачиванием сорцов нужных версий из нужных мест по нужным протоколам, обходом всех специальных случаев... В gentoo это решается написанием ебилда на каждый пакет. Но, вот, допустим, я пользуюсь оверлеем rust, чтобы иметь в системе расты разных версий, причём хоть самых-самых nightly. Иногда это требует правки ебилдов. Но мне приходилось отказываться от внесения каких-то изменений, потому что это были изменения, которые не примут в "апстрим", а самостоятельно поддерживать эти изменения я не готов совершенно. Внести и отправить пулл-реквест -- легко: поигрался с ebuild, выполняя работу emerge поэтапно, создал патч, оттестил его, отправил и забыл. А вот следить за актуальностью моего форка оверлея -- не, спасибо, вот заняться мне больше нечем. Если что, я могу и потерпеть пару месяцев, а там проблема тем или иным способом разрешится. > С другой стороны, если появилась проблема - отключаем config.site и собираем как > обычно. Вроде ничего сложного. Я в генту последнее время избегаю использовать keyword'ы типа ~amd64, потому что практика показывает, что эти флаги накапливаются в /etc/portage, и лет через десять это кончается тем, что либо emerge не может обсчитать зависимости, либо сборка внезапно обламывается в какой-то момент, и если месяц не обновлял мир, то потом такое обновление займёт пару часов (моего времени, не процессорного) в то, чтобы найти причины отказов и устранить их. И хорошо, если все эти причины выявятся на этапе обсчёта депендансов, а не начнут выскакивать в рандомные моменты сборки, в течение нескольких часов работы emerge. В общем, приемлимый для меня компромисс между надёжностью и конфигурабельностью со временем смещается в сторону надёжности. Тем более надёжность важна, если мы создаём не наколенное решение для применения на локалхосте, а вполне себе системное решение, у которого будут сотни и тысячи пользователей. Если мы попытаемся этот config.site впилить, например, в emerge и дополнить этим костылём с рестартом сборки, то встанет вопрос: как мы можем выяснить программно, что сборка обломалась из-за косяков с config.site? Или после каждого облома мы на всякий случай будем удалять config.site и делать рестарт -- а вдруг прокатит? > Но как я сказал, выигрыш не велик, а вероятность получить проблемы после очередных изменений в системе далеко не нулевая. Да, на самом деле эта вероятность получить проблемы и есть основная претензия к autotools. autotools -- это такое хакерское решение: минимумом усилий максимум результата. Но *nix в своём развитии ушёл за границы возможного для autotools, требования изменились. Изменилась и среда: сегодня нет необходимости тщательно проверять компиляторы C, потому что времена, когда каждый компилятор C имел свои собственные нюансы реализации, ушли в прошлое (почему C не считался кроссплатформенным языком в 80-е, да и в 90-е в общем-то? Как раз потому, что написать код, который скомпилируется двумя разными компиляторами и будет при этом работать как надо -- это был высший пилотаж программирования на C). Потому что есть стандарты и не только на компиляторы, но и на libc и на многое другое. Потому что есть pkg-config, который легко можно использовать непосредственно из makefile'а, проверяя наличие библиотек и их версии. Потому, что есть github, где очень легко отправлять pull-реквесты, получать их, создавать issues, обсуждать их, и находить решения: сегодня если софтина не собирается на какой-то особо хитрой конфигурации, то этим проблемам несложно найти решение и без autotools. Тем более, что autotools не решает этих проблем: configure в лучшем случае, поможет диагностировать эти проблемы. Потому, наконец, что сегодня из сорцов собирают только те, кому это интересно и кто готов разбираться в чём проблема, а не любой пользователь *nix, и просто потому, что других способов поставить софт не существует. А тем, кому интересно собирать софт из сорцов, совсем не обязательно иметь configure для того, чтобы делать сообщения об ошибках более информативными. Если комментаторы опеннета в большинстве своём и выступают против замены autotools на что-то ещё, то это их "старпёрский bias" -- опеннетовское когнитивное искажение, вызванное тем, что каждому опеннетовцу хочется выглядеть старпёром, а лучший способ выглядеть старпёром -- всегда выступать в пользу музейного софта и всегда против всего нового.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	+/–
	Сообщение от Mihail Zenkov (ok), 26-Окт-17, 10:34
	>> У меня своя система сборки. На все правки, включая написание программ для >> сборки и обработки config.cache ушло 3-4 часа. > Поддержание своей системы сборки будет требовать гораздо больше времени. На самом деле - не факт. Все зависит от задач. Если вы постоянно (ежедневно) меняете набор приложений - то да, лучше использовать готовый дистрибутив. Если набор приложений относительно стабилен - то затраты по времени не большие. Вы хорошо озвучили проблемы gentoo: 1. Глубокая модификация требует больших затрат по времени. 40-80 часов для задачи, которая в моем случае отняла 3-4 часа (да и то, если бы я сам не писал программы для этой задачи, то правки/тест сборочной системы отняли бы менее 30 минут). У меня в год на систему уходит 40-80 часов, да и то, только если я провожу эксперименты вроде обсуждаемого. 2. Поддержка своих изменений. Чем их больше, тем сложнее поддерживать. В итоге от них приходится отказываться. У меня есть похожая проблема, но на другом уровне: я часто модифицирую софт под свои нужды и большинство патчей не пойдут в апстрим. Их приходится поддерживать, что и отнимает основное время при возне с системой. > Если мы попытаемся этот config.site впилить, например, в emerge и дополнить этим > костылём с рестартом сборки, то встанет вопрос: как мы можем выяснить > программно, что сборка обломалась из-за косяков с config.site? Или после каждого > облома мы на всякий случай будем удалять config.site и делать рестарт > -- а вдруг прокатит? Как вариант. Можно еще научить систему составлять список таких случаев и сохранять логи неудачной и удачной сборки (или сразу делать с них diff) для быстрого разбора проблемы. > Потому что есть pkg-config, который легко > можно использовать непосредственно из makefile'а, проверяя наличие библиотек и их версии. Совершенно верно! > Если комментаторы опеннета в большинстве своём и выступают против замены autotools на > что-то ещё, то это их "старпёрский bias" -- опеннетовское когнитивное искажение, > вызванное тем, что каждому опеннетовцу хочется выглядеть старпёром, а лучший способ > выглядеть старпёром -- всегда выступать в пользу музейного софта и всегда > против всего нового. Тут не соглашусь. autotools давно пора выкинуть, но: 1. Зачем писать новые системы сборки, когда для 95% проектов достаточно make + pkg-config? Зачем генерировать майкфайлы, неужели нельзя сделать их статичными, а все переменные собрать в одном файле? 2. Если уж хочется написать новую систему сборки, зачем делать хуже, чем было? Один синтаксис управления cmake чего стоит: -DCMAKE_INSTALL_PREFIX=/usr против --prefix=/usr. 3. Если проект большой - сделайте свою компактную систему сборки и встройте ее в проект, типа как в AOSP, а не заставляйте тянуть и собирать кучу зависимостей.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	+/–
	Сообщение от Аноним (-), 25-Окт-17, 12:04
	> Весь этот вывод configure уже заучен наизусть, я его сам могу на клавиатуре набрать с закрытыми глазами, ан нет, автотулзы продолжают долбить в одну и ту же точку. Во-первых, у configure есть кеш, см. (./configure --help); во-вторых, даже если автор не предусмотрел (--enable-foo/--with-bar), любую закорюку/переменную можно переопределить в командной строке, так что configure будет думать, что проверка сделана и результат взят из кэша. Например, моэно убедить configure, что заголовок sys/wtf.h существует, и т. д. Такие дела :)
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

	161. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"	+/–
	Сообщение от Ordu (ok), 25-Окт-17, 20:14
	>> Весь этот вывод configure уже заучен наизусть, я его сам могу на клавиатуре набрать с закрытыми глазами, ан нет, автотулзы продолжают долбить в одну и ту же точку. > Во-первых, у configure есть кеш, см. (./configure --help); во-вторых, даже если автор > не предусмотрел (--enable-foo/--with-bar), любую закорюку/переменную можно переопределить > в командной строке, так что configure будет думать, что проверка сделана > и результат взят из кэша. Например, моэно убедить configure, что заголовок > sys/wtf.h существует, и т. д. Если я вожусь с командной строкой, то тормоза вносимые моими кривыми пальчиками и процессом мышления гораздо выше, чем тормоза ./configure. Это значит, что я только что сделал wget, потом tar jxf, вот сейчас делаю ./configure, потом буду делать make, потом искать способа потестировать работает ли без установки, потом решать, что делать с результатом -- вкатать в /usr/local при помощи make install, поставить в ~/local, поставить при помощи INSTALL_ROOT в /tmp, а потом вспоминать, читая man'ы и сорцы, как теперь всё это ebuild'ом раскатать в /usr, чтобы потом можно было бы удалить при помощи emerge... Короче эта история надолго. И в этой истории пара-тройка выполнений ./configure, пока я собираю все опции для него, которые я хотел бы ему передать, -- это вообще ни о чём.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема