а ещё бывают баги в компиляторах

багтрекер, не?

Ну у вас есть специальный человек который его будет каждый день читать?

я вообще не понимаю что за мода пошла распространять бинари с непонятной девелоперской машины, вместо машины майнтейнеров

я вообще не понимаю что за мода пошла распространять бинари с непонятной девелоперской машины, вместо машины майнтейнеров

Пакеты собираются обычно автоматически на билд-серверах.

Ну у вас есть специальный человек который его будет каждый день читать?

ну во первых зачем каждый день. а во вторых я с не линкую статически — мне нужно только следить за API/ABI что я и так делаю как обыкновенный программист

Пакеты собираются обычно автоматически на билд-серверах.

conan, docker, твой же подход со статической линковкой

conan, docker, твой же подход со статической линковкой

End-user'ы не будут ставить docker, чтобы запустить приложение. Для них нужен конкретный бинарник или лучше RPM/DEB пакет.

ну. так зачем линковать статически если всёравно заворачивать в деб/рпм?

А что за приложение то, если не секрет? Что оно делает?

ну. так зачем линковать статически если всёравно заворачивать в деб/рпм?

Грубо говоря, RPM - это лишь контейнер для дистрибуции приложения. Существуют десятки дистрибутивов, испольющие RPM: Fedora, CentOS, RHEL, OpenSUSE, ALT и во всех свои собственные наборы библиотек, несовместимые по API/ABI. Здесь и поможет статическая линковка.

Ещё хороша идея Flatpak для проприетарного ПО: внутри уже есть готовые рантаймы: libc, gtk и пр. Приложение пакуется и использует данные рантаймы для своей работы.

Если делать для всех этих ваших дистрибутивов пакеты, то там и надо прописать какие библиотеки нужны. А не линковать их статически.

Если делать для всех этих ваших дистрибутивов пакеты, то там и надо прописать какие библиотеки нужны. А не линковать их статически.

Готов делать пакет под каждый дистрибутив всех поддерживаемых версий?

Грубо говоря, RPM - это лишь контейнер для дистрибуции приложения. Существуют десятки дистрибутивов, испольющие RPM: Fedora, CentOS, RHEL, OpenSUSE, ALT и во всех свои собственные наборы библиотек, несовместимые по API/ABI. Здесь и поможет статическая линковка.

Проще собрать версию под каждый дистрибутив, актуальных дистрибутивов счетное количество.

Рпм это контейнер блин

рпм это не контейнер, это архив

Готов делать пакет под каждый дистрибутив всех поддерживаемых версий?

Подожди, ты ж сам предлагал делать рпм\деб?

а потому-что на неактуальный наверняка какая-то старинная версия qt с которой твое приложение не соберется

Даже в пределах одного дистрибутива будут серьёзные проблемы при динамической линковке. Например в Fedora 24 qt версии 5.6.2, а в Fedora 25-26 уже 5.7.1. Соберёшь под F25 и оно уже не запустится под F24.

у меня - нет

Рпм это контейнер блин

Почти. С обязательными полями вроде зависимостей, provides и т.п.

а какой смысл делать статические сборки под разные дистрибутивы?

одной сборки хватит всем

как в golang

Подожди, ты ж сам предлагал делать рпм\деб?

Да, но бинарник внутри должен быть собран статически (проприетарное ПО), дабы устанавливаться и работать во всех дистрибутивах с RPM/DEB.

В случае открытого ПО всё не так сложно. Мои пакеты в Fedora под все поддерживаемые версии собираются из одного спека билд-системой.

Я вот давеча установил Xilinx ISE, так там одно приложение требует рантайм от gcc3 и древнейший libmotif, так я его и не смог запустить.

В случае открытого ПО всё не так сложно. Мои пакеты в Fedora под все поддерживаемые версии собираются из одного спека билд-системой.

Да и в случае закрытого - можно обойтись установкой open build service на своем железе

Я вот давеча установил Xilinx ISE, так там одно приложение требует рантайм от gcc3 и древнейший libmotif, так я его и не смог запустить.

А вот если бы оно было слинковано статически, то работало бы где угодно.

А вот если бы оно было слинковано статически, то работало бы где угодно.

И дистрибутив занимал бы не 13 гигабайт...

Я вот давеча установил Xilinx ISE, так там одно приложение требует рантайм от gcc3 и древнейший libmotif, так я его и не смог запустить.

Ну вот и что проще: найти непонятный докер образ или сложить нужные либы в LD library path?

для меня проблема ждать пока он скачается с сайта вендора несколько часов

Ну вот и что проще: найти непонятный докер образ или сложить нужные либы в LD library path?

Вот и я тоже так подумал...

дистрибутив Xilinx ISE

когда у меня не заводился бинарь, а перекомпиливать было лень, я просто брал нужные либы из дебиана (где он заводился) и складывал рядом

а тут наворотили всяких докеров с виртуаклками и говорят что это проще

с одной стороны молодцы — мейнтернеры дистрибов так быстро работать не умеют

с другой стороны получается супер стабильный старинный кентос, а внутрях у него докер с непонятной начинкой и такими же непонятными дырами

l4 я ещё понимаю. для определенных юзкейсов нужно.

но толкать в докеры и прочие флап-чотам ради переносимости это странно

ради масштабируемости и модного web-scale ещё ладно

а так — лучше бы слои обратной совместимости пилили

ради масштабируемости и модного web-scale ещё ладно

У веб разработчиков часто есть проблема взять все это дерьмо и завести на нескольких хостах, у разработчиков на разных осях

Докер это очень хорошо

а. веб разработчики. нуда, нуда

У веб разработчиков часто есть проблема взять все это дерьмо и завести на нескольких хостах, у разработчиков на разных осях

Настроить хостинг разве что...

Сам проект никак не зависит от ОС

я щитаю, что если флейм не мешает разговорам про топик, то пусть будет. но вы как хотите. в ирц каналы без флейма обычно были слишком скучные, чтобы на них заходить.

а здесь ещё непонятно. вы тут все слишком молодые и слишком умные блин :(

вот так и дохнут все интересные каналы. я же сюда не для с++ пришел, а за похожими чужими мозгами

+++ Старайтесь не скатываться во флейм

Если делать для всех этих ваших дистрибутивов пакеты, то там и надо прописать какие библиотеки нужны. А не линковать их статически.

ничего что пакет с одними и теми же библиотеками в разных дистрах может называться по-разному?

ну по моему мнению пока самый вырвиглазный флейм тут был в виде стикера на полчата

мы же не виртуальным сексом тут занимаемся, ну

да и не следи? mark all as read...

а нафига ты щас сюда ходишь? чтобы ответить на вопросы от полутора тыщь потенциальных юзерей? и ой горе если их скрыл флейм?

ничего что пакет с одними и теми же библиотеками в разных дистрах может называться по-разному?

я не вижу почему проблемы мейнтейнеров это хуже чем проблемы создать контейнер или ещё какую обертку

тьфу блин не по русски получилось

так и не ходи - Leave Conversation в меню

ты такие экзистенциальные вопросы задаешь за тебя их никто не сможет решить

тьфу блин не по русски получилось

да, яннп

я имел ввиду что потратить время на написание/сбор пакета это примерно тоже самое что потратить время на написание докер-файла. в самом лучшем случае это вообще не взаимоисключающие вещи. в идеале в докере всёравно будет apt install my-web-scale-app.

но тут уже на вкус и цвет..

Std::common_type

Я за явность

В этом случае

Как и в том случае со сравнением контейнеров

IF(CMAKE_BUILD_TYPE MATCHES Debug) add_definitions("-DDEBUG") ...

я когда то делал так

нуда

Я вот хочу чтобы макс и мин работалт с итераторами, а то м*_элемент вспоминать...

И подключать еще хедер

но я так понимаю что сейчас лучше юзать чтото вроде COMPILE_DEFINITIONS. надо доки колупать.

Я вот хочу чтобы макс и мин работалт с итераторами, а то м*_элемент вспоминать...

Ну это принципиально стл алгоритм

когда надо прострелить себе ногу и запутать того, кто будет читать код

Парни хотите упоротое тестовое задание по С++?

Дава

Сделать так, чтобы компилировалось и выводило: int main() {     using namespace std;     cout << 36._plus1000  << "\n";   // 1036     cout << 512._plus1000 << "\n";  // 1512     cout << .0_plus1000   << "\n"; // 1000     cout << 0._plus1000   << "\n";// 1000 }

std::cout << "1036" << std::endl; // в таком же духе

Делов то