Compilador

"Projetos: fc new, build, run, test e fenner.toml"

Os subcomandos do fc para criar, compilar, executar, testar e documentar um projeto, e o fenner.toml com as dependências.

O que é e por que existe#

Compilar um .fxp solto com fc prog.fxp serve para um programa de um arquivo. Um projeto de verdade tem código em vários módulos, testes, configuração e dependências. Os subcomandos do próprio fc cuidam disso: cada um monta a linha de comando de sempre e a roda num processo filho (o mesmo fc.exe), propagando o código de saída. Nada de novo na compilação: é só conveniência e convenção de pastas.

O "projeto" é um .fxp, uma pasta com um único .fxp, ou nada (vale o único .fxp da pasta atual).

Criando: fc new#

terminal

fc new ola                 # um aplicativo de console (--app, o padrão)
fc new util --lib          # uma biblioteca
fc new tst --test          # um projeto de testes
fc new ... --cli | --wcl   # modelos de linha de comando e de interface gráfica (WCL)

O que o compilador criou para fc new ola (verificado):

texto

ola/ola.fxp               o programa
ola/ola.config            configuração do projeto
ola/fenner.toml           nome, versão e dependências
ola/.gitignore
ola/src/olaCore.fxm       um módulo de apoio
ola/tests/olaTests.fxp    os testes
ola/tests/olaTests.config

E o ola.fxp gerado:

Fenner

program ola;

// Programa de console. "fc run" compila e executa; "fc run -- Ana" passa argumentos.

uses System.Remainder, olaCore;

begin
  if ParamCount > 0 then
    WriteLn(Greeting(ParamStr(1)))
  else
    WriteLn(Greeting('mundo'));
end.

O ola.config gerado já usa as variáveis do .config:

config

Config  All  SourcePath  ($ProjectPath)\src
Config  All  OutputPath  ($ProjectPath)\out\($PlatformMode)

Ajustes pessoais vão em ola.config.local, que o .gitignore gerado já exclui.

Os subcomandos#

Comando	O que faz
`fc run [-- args]`	compila e executa; devolve o código de saída do programa. `fc run -- Ana` imprime `Olá, Ana!`
`fc build [--release]`	compila (`--release` = `-MRelease`); a saída vai para `out\MSWin64Release\`
`fc check`	só parse, semântica e geração de IR, sem ligar (`ok: nenhum erro em ola.fxp`)
`fc test [--filter=TEXTO] [--junit=r.xml] [--list]`	compila o projeto de testes (`Fenner.Testing`) e o executa
`fc clean [--all]`	apaga o que o build gerou, lendo do `.fxdeps`; `--all` inclui os caches
`fc doc [--out=pasta] [--format=…]`	= `fc --doc` (documentação)
`fc fmt [--check] [--diff]`	formata (formatador)
`fc add nome caminho`	dependência por caminho local, gravada no `fenner.toml`
`fc remove`, `lock`, `update`, `tree`, `run-script`, `help`	ver `fc help`

Num projeto --test, o fc test compilou e rodou, de verdade:

texto

testes: tst.fxp
[ OK ] tstSamples.TSumTests.SumPositives  (0 ms)
[ OK ] tstSamples.TSumTests.SumWithNegative  (0 ms)
[ OK ] tst.SomaNoPrograma  (0 ms)

3 teste(s): 3 passou(aram), 0 falhou(aram), 0 com erro, 0 ignorado(s) em 31 ms

(fc test --list lista os nomes sem rodar.) Veja Testes com Fenner.Testing para escrever os testes.

O fenner.toml#

config

[package]
name = "ola"
version = "0.1.0"

[dependencies]
util = "../util"                  # dependência por caminho: "fc add util ../util"
# util = "^1.2"                   # do registro local: "fc add util@^1.2"

# [scripts]                       # fc run-script nome
# fmt = 'fc fmt --check'
#
# [profile.dev]                   # padrão do build; [profile.release] vale com --release
# optimization = "0"
# debug = true
#
# [features]                      # fc build --features extra  ->  -DFEATURE_EXTRA
# default = []
# extra = []

Depois de fc add util ../util o arquivo ficou com util = "../util" em [dependencies] (mensagem: dependência "util" -> ../util registrada em fenner.toml). A pasta src\ de cada dependência entra no SourcePath. O fc lock grava o fenner.lock e o --locked exige que ele bata; há ainda fc publish, search, info, registry, yank e owner para publicar e baixar pacotes de um registro local ou remoto (opt-in: sem configuração, nada usa a rede).

Armadilhas#

Subcomando só vale como primeiro argumento, e só quando não existe um arquivo com esse nome. Numa pasta com build.fxp, fc build continua compilando o build.fxp; use fc project build para forçar o subcomando.
O nome do projeto precisa ser um identificador simples em ASCII (vira nome de DLL e de arquivos).
run e test só executam em MSWin64/MSWin32.
check e test são lentos (a RTL inteira entra); o check usa o servidor de compilação, se houver (fc --server).
O modelo --test precisa achar Fenner.Testing: a variável FC_TESTING, <fc>\testing ou <fc>\..\testing. O tst.config criado já vem com o caminho absoluto no SourcePath.
O fenner.toml só é lido pelos subcomandos; fc prog.fxp não o enxerga.
O manual mais antigo diz que fc fmt sem argumentos não formata o projeto; o fc help atual diz que formata (src, tests e fontes da raiz). Prefira passar os caminhos.
Opções úteis: --sourcepath=a;b, --quiet, --features a,b, --offline.

Veja também#

Linha de comando, Configuração, Packages.