This reverts commit ee71ea63ec.
Revert "reduce include deps for enlightenment_thumb binary"
This reverts commit cce14fa839.
both of these i reverted.... because they both CHANGE the define of
E_API like:
and this is wrong. e.h defines this so that these symbols are exposed.
E_API, EAPI and friends are desighned to explicitly expose symbols.
because if you try and make STRICTER binaries that only have symbols
for what was EXPLICTLY exposed like the CFLAG -fvisibility=hidden ...
then any api not explicitly marked with the attribute of visible which
that E_API macro is intended for... will be invisible. it will not
exist. this means a whole MOUNTAIN of modules stop loading as they
can't find these symbols. E_API isn't just source sugar tagging. it's
actually functional. i'd suggest using -fvisibility=hidden in your
CFLAGS by default. it's also not always portable between all compilers
so beware... (it was introduced years ago in gcc... i think clang
offers it. i don't know about icc or any others).
so since E_API is defined in e.h ... we may as well keep the e.h
include there instead of hand re-writing a list of includes. does
reducing the include deps really have an impact worth talking about on
compile time? the commit logs didn't say. but it does break module
loading and does it by adding lots of lines of code that are far mroe
easily broken now (this is an examplt). :)
great.. but if the src file htis was intended for doesn't include e.h
so it include config.h... then its kind of pointless isn't it? :)
SVN revision: 79997
* Remove vim modelines:
find . -name '*.[chx]' -exec sed -i '/\/\*$/ {N;N;/ \* vim:ts/d}' \{\} \;
find . -name '*.[chx]' -exec sed -i '/\/[\*\/] *vim:/d' \{\} \;
* Remove leading blank lines:
find . -name '*.[cxh]' -exec sed -i '/./,$!d'
If you use vim, use this in your .vimrc:
set ts=8 sw=3 sts=8 expandtab cino=>5n-3f0^-2{2(0W1st0
SVN revision: 50816
is pretty much almost perfectly working. i have fixed up some e_thumb stuff
and allowed e_thumb to be more responsive and skip items that are known to be
"generated" and bring them ahead in the list of things to thumb - so kind of
a priority skiplist - process what it KNOWS will be already done first
quickly and leave the slower stuff until later. efm is fairly well refined
now - as above. the test selector works nicely. also added an almost-sha1
generator - use sha1 sums of the path for thumbs - less likelihood of
collisions. the prolbme is given the small size of the input data... it's
hard to do well - but anyway :)
SVN revision: 24128
Mike Blumenkrantz
Carsten Haitzler
Chris Michael
Mike Blumenkrantz
Vincent Torri
Lucas De Marchi
Christopher Michael
Sebastian Dransfeld