Здравствуйте, eskimo82, Вы писали:

CS>>Где бы были Windows, MacOS или Linux если бы из них убрать GDI, CoreGraphics и GTK. Что-бы было если убрать DrawText и его поддержку ClearType из Windows API...
E>Там же. (кстати, в Linux, как в ОС, нет ни GDI ни единого прямого аналога: можете Xlib, а можете GTK, а можете и TUI — это все не части ОС, а сторонии либы).

Именно поэтому гуй под линукс такой страшнОй и неудобный.

Здравствуйте, Слава, Вы писали:

С>Именно поэтому гуй под линукс такой страшнОй и неудобный.

Гуй под что угодно страшный и неудобный потому что его не разрабатывают специалисты по UX.

Под Linux больше некоммерческих продуктов, куда UX-специалисты не привлекаются, поэтому так.

Сам Linux, с технической стороны, ни при чём.

Здравствуйте, Cyberax, Вы писали:

C>Electron — на JS, если нужно UI.

Сейчас скайп у меня занимает 800мб оперативки. Написан на электроне. Ничего нового в нём нет, и когда-то ему хватало 50 мб.

D>>Вообще у меня была мысль с ним слинковаться, но в бандл не пихать, чтобы библиотека пользовалась системным. Но, видимо, не судьба, я уже смирился.
C>Вот именно поэтому и не дают таким бредом заниматься. Так как это создаёт скрытые зависимости, которые Google может совершенно случайно сломать очередным update'ом системы.

Update'иться меньше надо. В том смысле, что пить меньше надо, работать меньше надо, жрать меньше надо и т.п. Повадились господа серверные делать хреновые пользовательские продукты (time to market!1111один мы первые!!!111одинодин), а потом их обновлять по сто раз. Это подло по отношению к конечному пользователю.

Здравствуйте, VladFein, Вы писали:

C>>>А руки проверять не пробовали на радиус кривизны?
D>>Давай курвиметр. Других рук вот только нет, сорри.
VF>

Курви́метр (от лат. curvus — изогнутый + греч. μέτρον — мера) — прибор для измерения длины...

Для измерения длины кривых на карте.

Здравствуйте, eskimo82, Вы писали:

E>Пишеш / редактируеш исходный makе и добавляеш к остальным make-ам (ndk-build). Реально там совсем не сложно.
E>Документации нет (на самом деле — хз, я не искал или читал), но можно посмотреть другие make-и как писать и интегрировать в ndk-build.

А нельзя ли поподробнее рассказать про этот процесс (показать пример makefile уровня "hello world")?
Сейчас я кое-как собираю программы для Андроид, использую Qt-for-android но не покидает ощущение черезжопности процесса.

Здравствуйте, Слава, Вы писали:

C>>>>А руки проверять не пробовали на радиус кривизны?
D>>>Давай курвиметр. Других рук вот только нет, сорри.
VF>>

Курви́метр (от лат. curvus — изогнутый + греч. μέτρον — мера) — прибор для измерения длины...

С>Для измерения длины кривых на карте.

ОК, а радиус кривизны где?

Здравствуйте, Dair, Вы писали:

D>>>Сборка нативного кода в Студии сделана на CMake, а сборка нативного кода в репах Андроида сделана на Blueprint/Soong.
D>>>Стоит совершенно непонятно зачем задача сопряжения одного и другого.
_>>Это ещё зачем? Для подключения сторонней библиотеки в C/C++ проект достаточно указать компилятору на папку с заголовочными файлами и на папку со скомпилированными библиотеками. Больше не требуется ничего. Причём дело не в том, что системы сборки разные — даже при одной системе сборки у проекта и библиотек нет никакого смысла в каком-то их объединение, т.к. именно ради такого разделения и придумано вообще понятие библиотек.
D>А скомпилированные под 4 архитектуры библиотеки я
D>а) Возьму где?

Скачиваешь исходники и собираешь (с помощью системы сборки, предлагаемой автором библиотеки) под нужные тебе архитектуры. Какие проблемы то?

D>б) Хранить буду как?

В каком смысле как? На диске видимо. ))) А какие ещё варианты? )))

A>А нельзя ли поподробнее рассказать про этот процесс (показать пример makefile уровня "hello world")?
Из того что есть сейчас под рукой (первые два варианта не используют инфраструктуру NDK никак, последний вариант — стандартный для Андроида, вам он будет наиболее интересен):

Пример 1: bash 4.3

Ничего делать не надо, кроме как правильно сконфигурить и сбилдить стандартными средствами*:

./configure -prefix=/data/local --exec-prefix=/data/local/bin --host arm-linux-androideabi && make

* Пути к тулчейну для кроскомпиляции должны быть прописаны в текущем PATH:

configure:2767: checking build system type
configure:2781: result: i686-pc-linux-gnu
configure:2801: checking host system type
configure:2814: result: arm-unknown-linux-androideabi
configure:3403: checking for arm-linux-androideabi-gcc
configure:3430: result: /home/user/opt/android-ndk-r10d/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc

Пример 2: самописный make для сборки динамической либы

ANDROID_NDK  ?= ~/opt/android-ndk-r9
TOOLCHAIN    ?= $(ANDROID_NDK)/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86_64
CROSSCOMPILE ?= $(TOOLCHAIN)/bin/arm-linux-androideabi-
SYSROOT      ?= $(ANDROID_NDK)/platforms/android-18/arch-arm

#ANDROID_NDK  ?= ~/opt/android-ndk-r10
#TOOLCHAIN    ?= $(ANDROID_NDK)/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64
#CROSSCOMPILE ?= $(TOOLCHAIN)/bin/aarch64-linux-android-
#SYSROOT      ?= $(ANDROID_NDK)/platforms/android-L/arch-arm64

CC := $(CROSSCOMPILE)gcc --sysroot $(SYSROOT)
LD := $(CROSSCOMPILE)gcc --sysroot $(SYSROOT)
MD := mkdir -p
RM := rm -f


INCDIR := include
OBJDIR := obj
LIBDIR := lib
#LIBDIR := lib64
SRCDIR := src

LIBS :=


$(OBJDIR)/%.o: $(SRCDIR)/%.c
    $(MD) $(dir $@)
    $(CC) -std=c99 -c $< $(addprefix -I,$(GINCDIR) $(INCDIR)) -fPIC -o $@


SRCFILES := sample.c
TARGETSO := sample.so
OBJFILES := $(addprefix $(OBJDIR)/,$(SRCFILES:.c=.o))

$(LIBDIR)/$(TARGETSO): $(OBJFILES)
    $(MD) $(dir $@)
    $(LD) $^ $(addprefix -L,$(GLIBDIR) $(LIBDIR)) $(addprefix -l,$(LIBS)) -shared -o $@



.PHONY: all, clean

all: $(LIBDIR)/$(TARGETSO)

clean:
    $(RM) $(OBJFILES)

# vim:noet:tw=80:ts=4:

** Для сборки стандартным make (linux).

Пример 3: Родной Android.mk из Native Activity

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE    := native-activity
LOCAL_SRC_FILES := main.c
LOCAL_LDLIBS    := -llog -landroid -lEGL -lGLESv1_CM
LOCAL_STATIC_LIBRARIES := android_native_app_glue

include $(BUILD_SHARED_LIBRARY)

$(call import-module,android/native_app_glue)

*** Для сборки через ndk-build из NDK (windows/linux).

C>>Electron — на JS, если нужно UI.

С>Сейчас скайп у меня занимает 800мб оперативки. Написан на электроне. Ничего нового в нём нет, и когда-то ему хватало 50 мб.

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

Здравствуйте, alex_public, Вы писали:

_>Скачиваешь исходники и собираешь (с помощью системы сборки, предлагаемой автором библиотеки) под нужные тебе архитектуры. Какие проблемы то?

Когда библиотека обновится, повторить? Кто этим будет заниматься? Мыжпрограммисты, это всё должно делаться автомагически.


D>>б) Хранить буду как?
_>В каком смысле как? На диске видимо. ))) А какие ещё варианты? )))

Диск — он у меня в компьютере.
А основное место кода — в репозитории. Которым пользуются другие разработчики. Разной квалификации.

Глубоко убеждён, что скомпилированные бинарники хранить в репозитории есть зло. В худшем случае для этого есть разные системы пакетов, можно хранить в них.

Задача такая: чтобы собрать проект, имея доступ к репозиторию, заняло минимальное время, и, что тоже немаловажно, было бы максимально просто. В случае разработки под Андроид — "открыть проект с помощью Android Studio, нажать "Build", подождать — готово".

Уже даже в случае с iOS у меня хуже — там cocoapods есть, и пара пакетов, ставящихся homebrew.


Я, вообще, уже сегодня всё сделал. Оно само скачивает (git submodules) нужные репы, запускает нужные скрипты. Всё работает вот как я написал. Правда, только на юниксах (ну или всякие cygwin), но у нас винды нет ни у кого, так что это ладно.

Здравствуйте, eskimo82, Вы писали:

D>>Я в Vim писал под Андроид, пока не было Андроид Студии, а на Эклипс у меня аллергия. А до этого писал в Vim практически вообще всё. Я умею в Vim, но настроить запуск разного и отладку не готов.
E>gdb запускается отдельно (надо пробросить порт на десктоп через adb, сервер кладется рядом вместе с нативными либами внутри apk, запускается через adb) от vim (и там есть TUI) или различные графические фронтэнды (ddd, insight).

E>Но ок, если не нравится — для вижуал студии есть плагины (nsight tegra например). С точки зрения пользователя проект под Андроид ничего не отличается от вендового, работа с отладчиком тоже интегрирована.

Для визуал студии, предположу, нужна Винда. А её нет.

А vim/ddd — знакомый мне по десктопно-линуксовой и эмбеддед набор, да.

Но Андроид Студия уже умеет дебажить нативный код, всё и так нормально.

D>Когда библиотека обновится, повторить? Кто этим будет заниматься? Мыжпрограммисты, это всё должно делаться автомагически.
Так можно и скрипт написать.

D>Задача такая: чтобы собрать проект, имея доступ к репозиторию, заняло минимальное время, и, что тоже немаловажно, было бы максимально просто.
Пишется скриптик. (Лет 14 назад у меня на рабочем столе была такая большая кнопка для сборки продукта под WinCE ...)

D>В случае разработки под Андроид — "открыть проект с помощью Android Studio, нажать "Build", подождать — готово".
Решение по сборке не должно касаться "начать кнопочку в IDE" никаким боком. В противном случае возникает куча трудностей которые придется одолевать.
Например: автоматическая сборка в процессе непрерывной интеграции (по событию комита или фикса, либо night builds).

Здравствуйте, eskimo82, Вы писали:

D>>Когда библиотека обновится, повторить? Кто этим будет заниматься? Мыжпрограммисты, это всё должно делаться автомагически.
E>Так можно и скрипт написать.

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

Потому что система сборки в NDK не умеет нормально работать с autoconf'ом, поэтому я написал "закат солнца вручную", клоны проектов из репы Андроида не используют (что было бы логично) ту же систему сборки, что и NDK, а ту систему сборки, которую они используют, я не разобрался, как даже собрать.

D>>В случае разработки под Андроид — "открыть проект с помощью Android Studio, нажать "Build", подождать — готово".
E>Решение по сборке не должно касаться "начать кнопочку в IDE" никаким боком. В противном случае возникает куча трудностей которые придется одолевать.
E>Например: автоматическая сборка в процессе непрерывной интеграции (по событию комита или фикса, либо night builds).

Да, конечно, так и есть, я намеренно упростил. В случае Андроида это

./gradlew assembleDebug

(ну или релиз). Хорошо что ровно это происходит по кнопке "собрать" в Студии.

Здравствуйте, Dair, Вы писали:

_>>Скачиваешь исходники и собираешь (с помощью системы сборки, предлагаемой автором библиотеки) под нужные тебе архитектуры. Какие проблемы то?
D>Когда библиотека обновится, повторить? Кто этим будет заниматься? Мыжпрограммисты, это всё должно делаться автомагически.

А как она обновится? Сама, неким магическим способом? Или кто-то всё же запустит ручками команду типа git pull? И что мешает тогда этому кому-то запустить помимо скачивания ещё и сборку?

D>>>б) Хранить буду как?
_>>В каком смысле как? На диске видимо. ))) А какие ещё варианты? )))
D>Диск — он у меня в компьютере.
D>А основное место кода — в репозитории. Которым пользуются другие разработчики. Разной квалификации.
D>Глубоко убеждён, что скомпилированные бинарники хранить в репозитории есть зло. В худшем случае для этого есть разные системы пакетов, можно хранить в них.

Есть разные подходы к данной проблеме. Кто-то считает, что каждый проект должен быть самодостаточным и таскать всё своё с собой (все используемые библиотеки живут в репозитории проекта). А другим удобнее создать свою коллекцию собранных библиотек, используемую из всех проектов. Это в каком-то смысле дело вкуса в организации внутренней инфраструктуры, так что не буду даже пытаться навязывать тут свой вариант.

Но в любом случае это никак не связано с тем фактом, что объединение процессов сборки проекта и используемых им библиотек — это сомнительная идея, которая противоречит самой концепции понятия библиотек (может тогда проще вообще взять чужие hpp/cpp файлы и скопировать к своим исходникам — зачем вообще библиотека, если она всегда будет строиться вместе с проектом?).

D>Задача такая: чтобы собрать проект, имея доступ к репозиторию, заняло минимальное время, и, что тоже немаловажно, было бы максимально просто. В случае разработки под Андроид — "открыть проект с помощью Android Studio, нажать "Build", подождать — готово".

Похоже на какую-то инструкцию для "секретарши-блондинки"... ))) Мне кажется, что программисты всё же могут позволить пару дополнительных шагов по настройке своей инфраструктуры перед началом работы с новым проектом. Тем более, что в случае с тем же Андроидом им перед этим понадобилось поставить как минимум SDK и NDK.

Здравствуйте, alpha21264, Вы писали:

A>А нельзя ли поподробнее рассказать про этот процесс (показать пример makefile уровня "hello world")?
A>Сейчас я кое-как собираю программы для Андроид, использую Qt-for-android но не покидает ощущение черезжопности процесса.

Использовать Qt-for-android не хочешь ты.

А то завтра Qt купит какой-нибудь негугл, и Qt перестанет выпускать обновления под андроид, и останешься у разбитого корыта.

Здравствуйте, Dair, Вы писали:

D>Нет сил держать в себе.
D>Содержит субъективную ненависть к платформе Android вообще и создателям её отдельных частей в частности.
... и вот опять

Строчка кода (Котлин):

_locationManager.requestLocationUpdates(GPS_PROVIDER, 1000, 0.0, this)

Ошибка:

None of the following functions can be called with the arguments supplied:
public open fun requestLocationUpdates(p0: Long, p1: Float, p2: Criteria!, p3: PendingIntent!): Unit defined in android.location.LocationManager
public open fun requestLocationUpdates(p0: String!, p1: Long, p2: Float, p3: PendingIntent!): Unit defined in android.location.LocationManager
public open fun requestLocationUpdates(p0: String!, p1: Long, p2: Float, p3: LocationListener!): Unit defined in android.location.LocationManager

Сука, кто так ошибки пишет? С++ уже десятки лет научился говорить, какой конкретно параметр не устраивает!

Господи, что ж за говно-то.

Предполагается, что будет использована последняя указанная сигнатура. this реализует LocationListener.

И вот всё у них так.

Здравствуйте, Dair, Вы писали:

D>Строчка кода (Котлин):

D>

_locationManager.requestLocationUpdates(GPS_PROVIDER, 1000, 0.0, this)

D>public open fun requestLocationUpdates(p0: String!, p1: Long, p2: Float, p3: LocationListener!): Unit defined in android.location.LocationManager[/q]

D>Предполагается, что будет использована последняя указанная сигнатура. this реализует LocationListener.

D>И вот всё у них так.

Я так понимаю, что this — это кто-то большой, типа Activity. На мой взгляд, удобнее/нагляднее создать обработчик прямо на месте параметра и вызывать из его функций все что требуется. Ибо, если this сам по себе большой и к тому же реализует еще что-то кроме LocationListener, то со временем не разберешься какая функция в этом классе от какого интерфейса и кто ее вызывает.

Здравствуйте, Cyberax, Вы писали:

C>Кто мешает взять обычную libxml, скомпилировать (можно даже статически) и прилинковать её? Кривизна рук опять?

Но вообще, согласись, это как-то неправильно, что каждая програмка под андройд должна принести свою копию libxml, sqlite и прочей мути, при том, что в андроиде все эти библиотеки присутствуют в составе операционной системы.

Здравствуйте, Dair, Вы писали:

D>StackOverflow вообще не в курсе что бывают такие проблемы.

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

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

Здравствуйте, Pzz, Вы писали:

Pzz>Но вообще, согласись, это как-то неправильно, что каждая програмка под андройд должна принести свою копию libxml, sqlite и прочей мути, при том, что в андроиде все эти библиотеки присутствуют в составе операционной системы.

Все-таки не каждая. Официально одобренный путь — это Java и публичный API.
И тащить все подряд в публичный API — тоже как-то неправильно.