Установка и первый запуск: сборка, лог старта, первый запрос

Обзор

2.1 Введение

При развёртывании нового серверного стека мучительное — обычно не написание кода, а подготовка среды: Node требует nvm и node_modules, Go — toolchain и GOPATH, классическому C-сервису нужен собственный конвейер сборки. Ответ XServer — свернуть всё это в этап сборки и внутрь бинарника: при сборке ваш GCC создаёт xs.exe, одновременно TCC-компилятор, полный набор заголовков SDK и определения системных библиотек пакуются со сжатием LZMA внутрь бинарника; в рантайме на целевой машине устанавливать не нужно ничего.

Так что «установка XServer» — это два действия: один раз собрать хост, затем запустить готовый каталог приложения (demo-single). С них и начнём.

2.2 Сборка хоста

Предусловий всего два: GCC (выбирается через --cc) и Python 3. В корне репозитория xserver:

$ build.bat                # минимальный вариант: default
$ build.bat sqlite xtp     # вкомпилировать расширения SQLite и XTP2
$ build.bat --list-extensions
доступные расширения: sqlite, xtp

Эквивалент для Linux — bash build.sh sqlite xtp. Конвейер сборки делает пять вещей:

Последний шаг стоит подчеркнуть: артефакт заменяется только после успешной линковки. При неудачной сборке xs.exe в каталоге release остаётся нетронутым — эту «защиту от сбоя» охраняет отдельный тест-кейс; прерывание сборки в любой момент не оставит битый бинарник.

2.3 Запуск демо и разбор лога

demo-single — полное демонстрационное приложение из репозитория (маршрутизация, шаблоны, SQLite, контролируемые страницы). Зайдите в каталог и запустите:

$ cd release/demo-single
$ ./xs.exe
[xs] config loaded: D:\GIT\xserver\release\demo-single/xs.json (1 servers)
[xs] server 'demo' class=http 127.0.0.1:9080 tls=off enabled
[xs]   default-host 'app' path=...\wwwroot devfile=...\main.c
[xs] engine started, workers=12
[xs] script loaded: ...\main.c (2.6 KB gen 1)
[demo] database opened: ...\db\main.db
[xs] server 'demo' http bound on 127.0.0.1:9080
[xs] running, press Ctrl+C to stop

Что только что произошло — построчно:

2.4 Отправка запросов

Откройте второй терминал и отправьте демо несколько запросов (весь вывод реальный):

$ curl -s http://127.0.0.1:9080/json
{"server":"xs3 demo","ok":true,"host":"app"}

$ curl -s http://127.0.0.1:9080/text
demo-single ok (from includes/demo_extra.h)

$ curl -s http://127.0.0.1:9080/api/v1/items/42
{"id":42,"name":"bench-write","created":1788494894}

$ curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:9080/nope
404
$ curl -sI http://127.0.0.1:9080/json
HTTP/1.1 405 Method Not Allowed
Allow: GET

Что только что произошло:

• /json прошёл через Handle_JSON в скрипте приложения — построение объекта через xvalue и сериализация (тема главы 18);
• /api/v1/items/42 попал в динамический маршрут /api/v1/items/{id}; захваченный сегмент 42 искался в SQLite (глава 17);
• /nope не совпал ни с одним маршрутом и обработчиком → 404;
• HEAD /json получил 405 + Allow: GET — в маске методов маршрута зарегистрирован только GET, и HEAD был отвергнут в слоте метода до обработчика. Реальная деталь маршрутизации; глава 17 расскажет, как обрабатывать HEAD.

2.5 Контракт

• Потоки: число workers фиксируется при старте и неизменно при горячей перезагрузке (изменения отклоняются).
• Варианты: вариант сборки определяет доступные скрипту символы — в варианте default нет sqlite3_* / xtp2_*; их использование ломает компиляцию.
• Данные: db/main.db демо — настоящий файл данных; экспериментируйте смело, пересборка репозитория его восстановит.

Частые ошибки

./xs
bind failed
./xs          /* снова и снова, не зная, кто держит порт */

netstat -ano | findstr 9080
/* сменить port в xs.json или завершить процесс-владелец */

copy xs.exe C:\tools\
C:\tools\xs.exe      /* config load failed */

/* xs.json и каталог исходников рядом с exe;
 * или явно указать путь к конфигу */
./xs D:\apps\myapp\xs.json

Упражнения