ну считай что не жил, кек

я и на C++ не очень много писал)

так что точно не жил

хорошо, conan имеет место быть под виндой, где с зависимостями туго

надеюсь, ты отдаешь себе отчет в том, что кросс-платформенно - включает в себя винду тоже

ну просто под линуксами зависимости решаются apt install libclang-dev какой-нибудь

поэтому как-то не думаю, что конан там надо

ну просто под линуксами зависимости решаются apt install libclang-dev какой-нибудь

из билдскрипта - нет, не решаются, там sudo нужен обычно

представь себе CI где собирается твой пакет - от чекаута до производства RPM-ок

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

ну просто под линуксами зависимости решаются apt install libclang-dev какой-нибудь

нужен

представь себе CI где собирается твой пакет - от чекаута до производства RPM-ок

Да, называется Koji. Внутри манифеста SPEC прописаны все -devel пакеты, которые нужны и они устанавливаются внутри изолированного chroot окружения. В нём же происходит сборка пакета. Результат выгружается.

(это пример если что, я знаю как это решается на CI сейчас и нет, это не очень хороший подход)

Да, называется Koji. Внутри манифеста SPEC прописаны все -devel пакеты, которые нужны и они устанавливаются внутри изолированного chroot окружения. В нём же происходит сборка пакета. Результат выгружается.

смотри выше

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

Это нормально в случае линуксов. Каждый новый билд - чистое окружение.

ну и с конаном оно тоже чистое - в систему ничего не ставится

Это нормально в случае линуксов. Каждый новый билд - чистое окружение.

чем плох подход конан? как по мне, всяко лучше

хотя, я смотрю тут

#holywar

#holywar

С таким заявлением вам лучше сюда: pro.cxx.holywars

то есть не в каждом дистре что-то мейнтенить. и хз, как там его собрал мейнтейнер. А есть репа с либами. И ты с неё качаешь. И на любом дистре у тебя одна и та же либа

то есть не в каждом дистре что-то мейнтенить. и хз, как там его собрал мейнтейнер. А есть репа с либами. И ты с неё качаешь. И на любом дистре у тебя одна и та же либа

Это no way в мире Linux. Годится только для проприетарщины.

Это no way в мире Linux. Годится только для проприетарщины.

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

Каждый пакет в дистрибутиве должен быть собран с использованием системных библиотек и слинкован с ними динамически. Статическая линковка и bundled-библиотеки запрещены.

*yawn*

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

Нет.

ну пусть в дистре собирают как хотят. Меня не волнует это

только в макоси адекваты остались походу..

Нет.

да

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

В .spec файле BuildRequires: написаны

В .spec файле BuildRequires: написаны

*yawn*

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

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

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

емнип, в мире макос так и сделано

Но хуже всего то, что все-равно придется знать все зависимости

А иначе есть возможность слинковаться с чем-то и даже не заметить, что там какую-то уязвимость нашли и нужно исправлять срочно у пользователей

к каждой проге просто написаны в простом файлике все зависимости

Ну в мире rust, go или erlang это не так. Там можно рекуррентно накачать кучу всего.

а чем мы хуже rust?

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

@berkus совсем беда?)

хз, кто тут ещё на расте пишет

наоборот хорошо же, и в go хорошо. делаешь go build и получаешь бинарик

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

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

разленился

и спишь спокойно, потому-что не знаешь что в там в нем внутри

вот-вот. не надо ленится, беркус, не надо

мало того, я могу даже под распберри пай так скросс-компилить - а это уже вообще ни в какие ворота

а то одна депенденси с автотулзами, вторая на симейк старом

мда.... одним словом - беда

как же без ебли то в С++

ну то есть прямо xargo run --target=arm64... и оп, бинарник под распи

я даже похудел от этого

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

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

ты о чём?) о -march=native?

или о том, почему бинарь скомпиленный не могёт подстроиться под платформу, где его запустили?

или о том, почему бинарь скомпиленный не могёт подстроиться под платформу, где его запустили?

Fat binary - Wikipedia en.wikipedia.org A fat binary (or multiarchitecture binary) is a computer executable program which has been expanded (or "fattened") with code native to multiple instruction sets which can consequently be run on multiple processor types. This results in a file larger than a normal one-architecture binary file, thus the name.

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

clang может, но ему для этого пришлось сделать нормальную модульную систему с бекендами, а не то говно которое в гцц

гм...

Fat binary - Wikipedia en.wikipedia.org A fat binary (or multiarchitecture binary) is a computer executable program which has been expanded (or "fattened") with code native to multiple instruction sets which can consequently be run on multiple processor types. This results in a file larger than a normal one-architecture binary file, thus the name.

я знаю про это

Fat binary - Wikipedia en.wikipedia.org A fat binary (or multiarchitecture binary) is a computer executable program which has been expanded (or "fattened") with code native to multiple instruction sets which can consequently be run on multiple processor types. This results in a file larger than a normal one-architecture binary file, thus the name.

что-то не видел, на практике это активно применяется?

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

ты помнишь тот идеологический спор когда Ричард Столлман сказал что плагины нарушат идеологическую целостность ГЦЦ и идите-ка нахуй - вот поэтому и не может

что-то не видел, на практике это активно применяется?

на ios - да, на маке тоже

гм, окей

есть fatelf но он чот не получил распространения - дистры в линуксе собирают только под одну платформу всегда

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

О! пока на винде, можно рейтрейсеры побенчить

или о том, почему бинарь скомпиленный не могёт подстроиться под платформу, где его запустили?

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

А в rust не нужно

А в rust не нужно

Rust на LLVM сделан, там не дураки

ERROR: S client not available

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

используй clang :-)

А clang уже научился ядро Linux собирать?

да

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

нет же

так, стоп. Они собрали?

ядро фряхи - да

нет же

там почти всё собирается, но они нашли какие-то странные оптимизации и оно не грузится в итоге кек

ахахахаххаах

ядро фряхи - да

фряха ВСЯ собирается от ядра до последнего сраного юзерспейса

кстати OpenBSD перешли с gcc 2.9 на clang

ну там clang дефолт компил

мммм, gcc 2.9 ..

кстати OpenBSD перешли с gcc 2.9 на clang

2.9!?!?

2.9!?!?

LGPL

интересно, сколько мне лет было...

как страшно жить

2.9 это порядка 1999 года, может 2001

ну-ка поглядим в историю

GCC 2.95.3 March 16, 2001

отлично, мне было 3 года

Что-то ты слишком молод, я уже в шестой класс ходил

я работал уже )

Что-то ты слишком молод, я уже в шестой класс ходил

ну что ж поделаешь :-)

ребята, я что-то делаю не так?: CXIndex index = clang_createIndex(0, 0); CXTranslationUnit unit = clang_parseTranslationUnit( index, "header.hpp", nullptr, 0, nullptr, 0, CXTranslationUnit_None); unit всегда == nullptr, т.е. не получается создать юнит трансляции кода (если что, то речь о libclang)

кто тут у нас под шланг ковырялся?)

лол

забавно то

что когда я дал абсолютный путь, то все заработало

WTF

фигали оно относительный путь не жует? Сурс возле exe'хи лежит

(да, я из-под винды!)