On Mon, Jan 16, 2017 at 10:39 PM, Carsten Haitzler <[email protected]> wrote:
> On Mon, 16 Jan 2017 12:00:24 -0200 Gustavo Sverzut Barbieri
> <[email protected]> said:
>> - pure gnu make is great, with very capable macros on its own, you
>> can auto generate rules, recursively include files... that leads to a
>> single 'make' (not recursive) yet nicely split into individual files
>> like the linux kernel. However it may be bit slow on big projects,
>> it's showing its age on Linux or Buildroot if you don't have a fast
>> enough CPU.
>
> we already depend on gnu make anyway... so nothing new. :) makefiles are
> something most c/c++ devs know so it's a "devil you know" with gnu make being
> the far more friendly make variety which is decent enough to not have to do
> workarounds for.
well, if you rely on macros to create rules for you it's not that
easy, been there, did that, debug is a major PITA, things like some
variables and functions you declare may depend on order, which is not
that trivial to spot and there are no errors, just silent expansion to
empty.
the kernel-like makefiles uses lots of that AND dynamic configurations like:
obj-$(KCONFIG_OPT_NAME) += file
this is tad slow to compute, thus every make command will take a while
to execute. In contrast ninja is explicit and all is pre-computed,
then for regular development where you're not changing options, it's
noticeable faster.
> i actually would be perfectly happy going back to subdir makefiles as you can
> just cd to the right place in the tree and "make" from there easily enough...
> :)
it's a bad practice, but if you insist you can always add Makefile in
the subdirs with:
make -C ../..
and things like that.
>> I have lots of experience with autotools (efl, and all other
>> projects), cmake (which I did the initial autotools->cmake conversion)
>> and kconfig (my recent project soletta uses that). So consider I may
>> be biased, but:
>>
>> I'd *NOT* go with glue in shell because that usually needs lots of
>> complex data structures to simplify the code, otherwise you waste lots
>> of time working around poor hash support to do it in shell... Pure
>> shell would also not be my favorite tool to write the build system per
>> se since tracking parallel tasks with it is more complex than with
>> make/ninja or other tools meant for that.
>
> oh no. was thinking pure sh just to replace "configure" and generate a
> Makefile.conf that is included from a hand rolled Makefile. basically the
> kconfig bit of kconfig with everything needed for running compile tests to
> detect something (we can split the tests into a configure_tests dir and just
> issue a compile via a wrapper func from the shell and gather return code). so
> just replacing functionally what configure and/or kconfig does in a very
> simple
> way.
>
> can kconfig gather pkg-config cflags/libs and versions? can it do feature
> tests
> (does func x exist in library y (or more specifically does a compile succeed
> with a func x() in src code if it also #includes x/y/z and -lx -ly -lz -Lx -Ly
> -Lz)?). fundamentally these tests in autotools are very easy to DIY on the
> os's
> we support. does kconfig do this or will e have to "roll our own" ?
no, kconfig needs to be fed with such information. For example you go
and write a shell script that will do:
if pkg-config --exists freetype2; then
cat << EOF >> .kconfig.deps
config HAVE_FREETYPE2
bool
default y
config FREETYPE_CFLAGS
string
default "`pkg-config --cflags freetype2`"
config FREETYPE_LIBS
string
default "`pkg-config --libs freetype2`"
EOF
fi
Which you could make to a sh function "check_pc name>=version"
Then in your entrypoint Kconfig:
include .kconfig.deps
Since there are no "prompt" in above, it won't be user-visible, but
other Kconfig files can do:
config USE_EVAS
bool "Enable Evas"
default y
depends on HAVE_FREETYPE2=y
help
Evas is EFL's retained canvas library, it will manage objects
and update the screen as needed.
This prompt will be enabled only if HAVE_FREETYPE2=y. Usually people
also add a message/comment to let user know something important was
disabled:
comment "Evas is disabled (needs freetype2)"
depends on !HAVE_FREETYPE2=y
In our makefiles, we'd simply base on USE_EVAS:
obj-$(USE_EVAS) := evas_main.c ...
Which will expand to:
obj-y := evas_main.c
or:
obj-n := evas_main.c
Then you usually have macros that prepend the directory as scope and
results something like:
gcc -shared -o libevas.so $(src-lib-evas-obj-y) ...
>> TL;DR: the only complete solution is CMake, but if I would pick
>> something specifically for EFL use cases I'd go with kconfig + ninja
>> with glue in Python -- or Perl (since kconfig uses that) or Lua (since
>> efl uses that). Second option is traditional kconfig + gnu-make.
>>
>> https://github.com/solettaproject/soletta is an example of kconfig +
>> gnu-make + python.
>>
>> - kconfig is embedded into the project as pure C code (not an extenal
>> dep) https://github.com/solettaproject/soletta/tree/master/tools/kconfig
>>
>> - https://github.com/solettaproject/soletta/tree/master/tools/build
>> base definitions
>
> i am not sure i can quickly get from that if it can do pkg-config checks or
> compile checks and so on like above... can it?
You need something else, like I wrote below. In soletta we use
dependencies.json to specify what we used in autoconf (pkg-config
module, check lib, check header...). It's parsed by a Python script
that executes actual commands and outputs the ".kconfig.deps" I wrote
above (if you take Soletta it will generate Kconfig.gen).
>> -
>> https://github.com/solettaproject/soletta/blob/master/data/jsons/dependencies.json
>> we defined our dependencies file format in JSON, which we parse and execute
>> from Python. Could be "YAML" or something like that. But JSON is not that
>> cumbersome and it's easy to write a jsonschema to validate it.
>
> now i begin not to like this. write a file that then, goes through a generator
> to generate another file that goes through another generator that... it's
> autotools all over.
This is not required, just us in Soletta thought it would be simpler.
Kconfig will just use its own files and output make/header compatible.
It doesn't find anything on its own.
You could write it all in Lua, Python, C or whatever, given that you
output .kconfig.deps like in the example above.
> my thoughts on plain sh were just to execute a series of checks and
> information
> gathering into a Makefile.conf (and config.h) then include that makeifle (and
> of course config.h). we'd have shell funcs like
>
> #!/bin/sh
> ./conf/configure_funcs.sh
>
> # pars arguments like --prefix=XXX and set vars accordingly
> parse_args
>
> # below will append VAR1 to CHECK_FUNCS var like "VAR1 VAR2 VAR2" so
> # a simple for I in $CHECK_FUNCS; do ... can iterate over them when
> # write_makefile_conf is called and just write out makefile vars like if that
> # var is true/false etc. and will also just generate a simple c file to test
> # compile
> check_c_func VAR1 funcname inc1.h inc2.h inc3.h -Ixxx -llib1 -Ldir2
> # like the above but specifically runs pkg-config --cflags and set VAR2_CFLAGS
> # and VAR2_LIBS accordingly
> check_pc VAR2 lib1 lib2 lib3
> # checks lib1 is at least 1.2.3 version - optional
> check_pc_version lib1 1.2.3
> # checks lib2 is between 1.2.3 and 2.4.5
> check_pc_version lib2 1.2.3 2.4.5
>
> if test x$FEATRUE_X = xyes; then
> check_pc VAR3 libxx libyy
> check_pc_version libxx 1.5.0
> check_pc_version libyy 1.6.0
> fi
>
> # and so on...
>
> # at end of shell
> write_makefile_conf Makefile.conf
> write_header_conf config.h
>
> or you get the idea...
Yes, up to "and so on" is what our Python + dependencies.json does...
but instead of writing in pure-shell, we did in Python + JSON. We
could do in pure shell, but we disliked that.
the final 2 commands "write_makefile_conf" and "write_header_conf" are
managed *by kconfig*, as it will take the results of your checks
(check_pc, check_c_func...) + the user settings, then compute the
resulting files for you.
this part is done by a C binary hosted in your own project (it's
compiled for you by kconfig), in soletta it's ./tools/kconfig/conf
So to write your idea in a more real scenario, it becomes:
--->8--- conf/configure_func.sh --->8---
function check_pc() {
local _name=`toupper $1`
if pkg-config --exists $1; then
cat << EOF >> .kconfig.deps-tmp
config ${_name}_FOUND
bool
default y
config ${_name}_CFLAGS
string
default "`pkg-config --cflags $1`"
config ${_name}_LIBS
string
default "`pkg-config --libs $1`"
EOF
else
cat << EOF >> .kconfig.deps-tmp
config ${_name}_FOUND
bool
default n
EOF
fi
}
--->8--- check-deps.sh --->8---
#!/bin/sh
./conf/configure_funcs.sh
rm -f .kconfig.deps .kconfig.deps-tmp
check_c_func VAR1 funcname inc1.h inc2.h inc3.h -Ixxx -llib1 -Ldir2
check_pc VAR2 lib1 lib2 lib3
check_pc_version lib1 1.2.3
check_pc_version lib2 1.2.3 2.4.5
check_pc VAR3 libxx libyy
check_pc_version libxx 1.5.0
check_pc_version libyy 1.6.0
mv .kconfig.deps-tmp .kconfig.deps
--->8--- Kconfig --->8---
include ".kconfig.deps"
config PREFIX
string "Where to install EFL"
default "/usr"
config USE_EVAS
bool "Enable Evas"
default y
depends on HAVE_FREETYPE2=y
help
Evas is EFL's retained canvas library, it will manage objects
and update the screen as needed.
This prompt will be enabled only if HAVE_FREETYPE2=y. Usually people
also add a message/comment to let user know something important was
disabled:
comment "Evas is disabled (needs freetype2)"
depends on !HAVE_FREETYPE2=y
--->8--- Makefile --->8---
.kconfig.deps: check-deps.sh Makefile
./check-deps.sh
-include .config # generated by make menuconfig, oldconfig...
and so on... You add .kconfig.deps as a dependency of 'make
menuconfig' or 'make oldconfig' (or all rules that touch '.config'),
then 'make all' depends on .config and you get the results you want.
it will output include/generated/autoconf.h or $KCONFIG_AUTOCONFIG
with your header file.
--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (16) 99354-9890
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
