Detalhes
problema: kw bd doesn't support --remote
Basicamente , o comando para instruir o kw a dar build e deploy não funcionava quando recebia alguma flag tanto do build quanto do deploy (aparentemente isso foi feito de propósito e , como apontado pela contribuidora melissawen, very bad UX)
Minha ideia , primeiramente era fazer o kw bd aceitar as flags do deploy e depois,em um próximo patch ,aceitar flags do build,como orientado pelo David. A função "parse_build_and_deploy_options()" pega todas flags que são digitadas atráves do comando kw bd e jogam elas no limbo , retornando um erro de flag invalida, para fazer o kw bd aceitar as flags do deploy foi nessecário remover essa função e alguns tratamentos de erros dela. Resposta que obtive :
Portanto,decdidi fazer um patch que aceita as flags tanto do build quanto do deploy, com exeção das flags que não devem ser permitidas segundo o Siqueira
Assim , para fazer essa mudança tive que rerfomular a função "parse_build_and_deploy_options()" de modo que ela filtre as flags do deploy e do build , junto com seus respectivos argumentos , e coloque em duas Strings de deploy e de build
alteração :
function parse_build_and_deploy_options()
{
#build options
local long_options='help,ccache,cpu-scaling:,warnings::,save-log-to:,llvm,verbose,cflags:'
local short_options='h,S:,w::,s:'
local file_name_size
# #deploy options
long_options+=',remote:,local,reboot,no-reboot,modules,force,setup,
verbose,create-package,from-package:,boot-into-new-kernel-once'
short_option+=',r,m,f,v,p,F:,n'
options="$(kw_parse "$short_options" "$long_options" "$@")"
if [[ "$?" != 0 ]]; then
options_values['ERROR']="$(kw_parse_get_errors 'kw bd' "$short_options" \
"$long_options" "$@")"
return 22 # EINVAL
fi
while [[ "$#" -gt 0 ]]; do
case "$1" in
--help | -h)
# build_and_deply_help "$1"
build_and_deploy_help "$1"
exit
;;
--menu | -n)
build_options+="$1 "
shift
;;
--cpu-scaling | -S)
build_options+="$1 $2 "
shift 2
;;
--ccache)
build_options+="$1 "
shift
;;
--llvm)
build_options+="$1 "
shift
;;
--cflags)
build_options+="$1 $2 "
shift 2
;;
--verbose)
build_options+="$1 "
deploy_options+="$1 "
shift
;;
--warnings | -w)
# Handling optional parameter
if [[ "$2" =~ [0-9]+ ]]; then
build_options+="$1 $2 "
shift 2
else
build_options+="$1 "
shift
fi
;;
--save-log-to | -s)
build_options+="$1 $2 "
shift 2
# After this line , we have deploy options
;;
--remote)
deploy_options+="$1 $2 "
shift 2
;;
--local)
deploy_options+="$1 "
shift
;;
--reboot | -r)
deploy_options+="$1 "
shift
;;
--no-reboot)
deploy_options+="$1 "
shift
;;
--modules | -m)
deploy_options+="$1 "
shift
;;
--force | -f)
deploy_options+="$1 "
shift
;;
--create-package | -p)
deploy_options+="$1 "
shift
;;
--from-package | -F)
deploy_options+="$1 $2 "
shift 2
;;
--boot-into-new-kernel-once | -n)
deploy_options+="$1 "
shift
;;
--)
shift
;;
*)
return 22 # EINVAL
;;
esac
done
}
Pull request:
A maneira que eu testei esse PR foi absurdamente ineficiente,pois aparentemente os arquivos txt mentem para voçê, eu passava a String deploy options e a String build options para um arquivo deploy.txt e build.txt , respectivamente , lá eu análisa como os argumentos estavam formatados e com isso eu suponhava como iria funcinar se eu jogasse no kw bd
Resposta do PR:
O problema era como os espaços entre os argumentos eram tratados no meu código
build_options+="$1 "
quando só existia um argumento, o argumento ficava com um espaço,o mesmo ocorria com o ultimo argumento,para resolver isso , bastava eu usar arrays no lugar de Strings como armazenador de strings,já que o espaçamento vai ser por cada elemento do array
novo método de guardar os argumentos
build_options+=("$1")
Depois de duas semanas , recebo o feedback:
while [[ "$#" -gt 0 ]]; do
case "$1" in
--help | -h)
# build_and_deply_help "$1"
build_and_deploy_help "$1"
exit
;;
--cpu-scaling | -S)
build_options+=("$1" "$2")
shift 2
;;
--ccache)
build_options+=("$1")
shift
;;
--llvm)
build_options+=("$1")
shift
;;
--cflags)
build_options+=("$1" "$2")
shift 2
;;
--verbose)
build_options+=("$1")
deploy_options+=("$1")
shift
;;
--warnings | -w)
# Handling optional parameter
if [[ "$2" =~ [0-9]+ ]]; then
build_options+=("$1" "$2")
shift 2
else
build_options+=("$1")
shift
fi
;;
--save-log-to | -s)
build_options+=("$1" "$2")
shift 2
#after this line only deploy options
;;
Basicamente , o Siqueira quer que tratamos os argumentos do kw bd dentro das funções de tratamentos de argumentos do kw b e do kw d invés de criar uma função que trata esses argumentos dentro do próprio arquivo do kw bd, pois , segundo ele , isso ficaria mais fácil de manter , já que todos argumentos do kw b, seriam automáticamente adicionados no kw bd, o mesmo com kw .
Depois de mandar o PR errado e concertar o PR, fui orientado a apagar tudo que eu fiz e fazer tudo de novo de uma maneira diferente
comecei a me questionar sobre o pensamento do siqueira , primeiro pensei , mas nem todos argumentos do kw b e do kw d ,são aceitos pelo kw bd , como o Siqueira, mencionou,certo?
Além disso , certos argumentos devem ser tratados dentro do próprio kw bd, por exemplo o kw bd --help, que deve ser chamando dentro do arquivo kw bd,pois lá , tem a função help
Mesmo com esses casos , cheguei a conclusão que dava para fazer uma gambiarrazada para resolver isso,porém quando fui tentar colocar a solução em prática,percebi que o código ficara uma completa infelicidade , para não falar outra coisa , cheio de duplicações e adicionava 100 linhas a mais, isso tornava o código completamente o oposto do que o Siqueira comentou.
A única solução que pensei foi , passar todos argumentos para a função kw b e a função kw d, e basicamente fazer o que eu fazia dentro do kw bd nessas funções,porém,eu precisaria, tratar tanto os argumentos do build quanto do deploy, em um mesmo arquivo , por exemplo, no kw b , eu teria o while tratando os casos do deploy,não só o do build, porém, somente jogando fora os argumentos do deploy. Isso não ficaria fácil de manter , pois ao adicionar novos argumentos no build , teriamos que adicionar esses mesmo argumentos dentro do while do arquivo do kw d.
Não sei se o Siqueira pensou na dificuldade de fazer isso de uma maneira otimizada ou se mesmo pensou em como fazer isso,talvez ele só tenha jogado a ideia no ar mesmo.Todavia , até o momento atual , não consegui pensar em algo otimizado para resolver isso.
Pedido de esclarecimento para o Siqueira :
Respota do Siqueira:
Entendi mais ou menos a idea que o Siquera tinha na cabeça , mas na hora de implementar essa idea é que o bicho pega! A implementação dessa idea causa diversos conflitos com a estruturação do próprio projeto, tentei diversas alternativa para ludibriar esses problemas , mas sempre surgia outro...
Um dos problemas que encontrei no caminho foi o kw parse, dentro da própria parser_build_shared eu teria que colocar as flags do deploy nas variaveis long_options e short_options, o mesmo vale para a futura função parser_deploy_shared, tal fato levaria a depência de um arquivo com outro , não queremos isso! Encontrei um jeito de burlar isso( mais ou menos) dentro do tratamento dos argumentos do parser_build_shared(), tudo que não era flag do build do caso da shared , era tratado como possível flag do deploy,armazenando essas flags em um array global e ,depois , passando para o parser_deploy_shared(). Porém, esse modo entrava em conflito com o próprio código do kd build, como a função parser_build_shared() faz parte do kw build , caso o usuário passe um flag que não comece com "--" , ou seja , invalida , essa função tem que ser responsável por retornar um erro, mas ai que vem a confusão , existem flags no deploy que precisam de argumentos obrigatórios , e esses argumentos vem no formato sem o "--" , logo , nosso while case vai identificar isso como um erro.
Ainda com duvida sobre a implementação desse pseudocódigo...
