-
Notifications
You must be signed in to change notification settings - Fork 0
/
internalsDesign.txt
38 lines (31 loc) · 1.78 KB
/
internalsDesign.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Como vai funcionar o hell internamente?
Nota: a partir de 30/04/15 foi decidido que Haskell não era uma ideia tão boa,
então bora usar C++, já que o problema demanda mta IO, e não faz tanto
processamento que poderia ser 'Lazy'ado (além de ser melhor descrito
proceduralmente, com estados) ;]
A ideia é o ~Haskell~ C++ mandar, e o script servir só pra dafinir as builds.
Inclusive, script provavelmente só será rodado quando precisar refazer o db
(quando o script de construção tiver sido atualizado).
Pensando bem, é útil podermos settar variáveis direto no script pela cli,
como por exemplo 'debug=1' (lembrando que os valores ficarão em strings).
Assim sendo, contando que cada chamada ao hell essas coisa podem mudar,
não tem muito como só rodar o script hora que o tal muda... Assim sendo,
acho melhor o lua mandar, ler opções de linha de comando, ler os scripts,
e daí sim chamar o ~Haskell~ C++ pra verificar dependências, quem mudou e
quem não, e soltar os comandos.
Além disso, parsear opções é mais sussa no Lua, então ele começa e chama
os paranauê em ~Haskell~ C++ depois.
Problema é que não acho de jeito maneira um jeito de fazer a
biblioteca em ~Haskell~ C++ num .so e linkar no Lua direto (que nem faz em C),
sem contar que linkar do C, que linka o ~Haskell~ C++ dá muito trampo.
Solução: roda pelo ~Haskell~ C++, chama o script, e depois faz suas treta.
No Lua, quem manda é a table 'hell', que tem uns campos interessantes, bem
explicadinhos no 'src/lua/hell.lua', dá uma olhadinha lá =]
Esquema simplificado do fluxo do rolê
=====================================
1. Roda o script e manja as targets
2. Target existe?
2.a não => ERROR ('target inexistente!')
2.b sim => continua no 3. =P
3. Verifica dependências
4. Executa comandos