Vit (30.06.2019 12:31, просмотров: 132) ответил Точка опоры на Начинаю говнокодить под Линуксом в Geany. Заголовочные файлы.-
- Ссылка asm -> asm-generic это не правильно. asm - это платформо-зависимые хидеры. - kaf1(30.06.2019 17:46)
- а что правильно? правильно в исходник положить зависимости? - Vit(30.06.2019 21:50)
- Правильно в makefile прописать нужное -I... - kaf1(30.06.2019 21:53)
- и с какого перепугу без make компилер должен становиться раком? это же нативная, а не кросс-компиляция - Vit(30.06.2019 21:55 - 21:58)
- Не должен. Но каждый раз набивать километровые строки как-то влом, да и ошибешься десять раз. Проще Makefile. - kaf1(30.06.2019 21:58 - 22:09)
- у ТС #include Vit(197 знак., 30.06.2019 22:03)
- asm/io.h туда лезут или если приспичило (но тогда понимают что делают) или если хотят наговногодить. Обычно стираются дальше posix не отходить. - kaf1(30.06.2019 22:17 - 22:25)
- ога. всё будет ioctl - Vit(30.06.2019 22:18)
- и эцих с гвоздями - kaf1(30.06.2019 22:29)
- и кроме Торвальдса никто не использует linux/io.h --> - Vit(30.06.2019 23:52, ссылка)
- Было бы странно, если бы оно внутри ядра не использовалось. - kaf1(30.06.2019 23:56 - 01.07.2019 00:00)
- было бы странно, если бы каждое первое использование Vit(79 знак., 01.07.2019 00:09)
- А что значит "требовало бы бодаться с пазами на арч"? - kaf1(01.07.2019 00:13)
- то и значит, что нужно пути найти и вписывать. для каждого проекта с io.h. чтобы, мля, не забывать под какую архитектуру ядро. вместо просто включить хедер. причём с версиями ядра/хедеров и симлинками всё без вопросов, а тут вдруг появляются Vit(27 знак., 01.07.2019 00:25)
- Ну тогда используйте autotools. Я про то, что нужно сильно аргументировать использование io.h в основном проекте. Без выноса этого безобразия в отдельный подпроект, а может даже в модуль ядра. - kaf1(01.07.2019 00:39)
- Чую что-то интересное... Но нет перевода для нубов. - Точка опоры(01.07.2019 23:41)
- Ну тогда используйте autotools. Я про то, что нужно сильно аргументировать использование io.h в основном проекте. Без выноса этого безобразия в отдельный подпроект, а может даже в модуль ядра. - kaf1(01.07.2019 00:39)
- то и значит, что нужно пути найти и вписывать. для каждого проекта с io.h. чтобы, мля, не забывать под какую архитектуру ядро. вместо просто включить хедер. причём с версиями ядра/хедеров и симлинками всё без вопросов, а тут вдруг появляются Vit(27 знак., 01.07.2019 00:25)
- А что значит "требовало бы бодаться с пазами на арч"? - kaf1(01.07.2019 00:13)
- было бы странно, если бы каждое первое использование Vit(79 знак., 01.07.2019 00:09)
- Было бы странно, если бы оно внутри ядра не использовалось. - kaf1(30.06.2019 23:56 - 01.07.2019 00:00)
- и кроме Торвальдса никто не использует linux/io.h --> - Vit(30.06.2019 23:52, ссылка)
- и эцих с гвоздями - kaf1(30.06.2019 22:29)
- ога. всё будет ioctl - Vit(30.06.2019 22:18)
- asm/io.h туда лезут или если приспичило (но тогда понимают что делают) или если хотят наговногодить. Обычно стираются дальше posix не отходить. - kaf1(30.06.2019 22:17 - 22:25)
- у ТС #include Vit(197 знак., 30.06.2019 22:03)
- Не должен. Но каждый раз набивать километровые строки как-то влом, да и ошибешься десять раз. Проще Makefile. - kaf1(30.06.2019 21:58 - 22:09)
- и с какого перепугу без make компилер должен становиться раком? это же нативная, а не кросс-компиляция - Vit(30.06.2019 21:55 - 21:58)
- Правильно в makefile прописать нужное -I... - kaf1(30.06.2019 21:53)
- а что правильно? правильно в исходник положить зависимости? - Vit(30.06.2019 21:50)
- Ссылка asm -> asm-generic это не правильно. asm - это платформо-зависимые хидеры. - kaf1(30.06.2019 17:46)