hi back
On 09/08/11 20:34, Glyn Kennington wrote:
pancake wrote:
*) about -lmagic .. it would be better to have a single .mk with that
check and being enabled with USE_LIBMAGIC=YES so if USE_LIBMAGIC and
HAVE_LIBMAGIC is enabled this flag is appended to ldflags.
What I was planning was to move the "if HAVE_LIB_MAGIC" block out of
each of the relevant binr/*/Makefiles and into binr.mk, inside an ifeq
that checks whether the current BINDEPS contain "r_core"... Then the
same for all the other dependencies: r_hash: -lm, r_fs: libgrubfs.a etc.
yep, that sounds good too. a single .mk for each library would be
enought to define such dependencies inside. So the DEPS var can
be expanded to include each .mk to get all the required .o , the .so,
the .a and the dependencies (-lmagic, -lsocket, ..)
*) more on magic.. the idea will be to have our own implementation of
libmagic included inside radare. any volunteer? i think openbsd one is
the more decent one.. but still bloated.. so a reimplementation would be
good. It's in TODO for 0.9. Having -lmagic as dependency makes porting a
bit complex.
The only implementation I can find is Ian Darwin's[1], which is
apparently in BSD, OSX, cygwin and every linux distro I've ever used. I
agree it'd be good to have a lightweight internal version for when the
system doesn't have its own - but I also like having all my custom
locally-installed magic files, so I'd be in favour of keeping -lmagic as
an optional dependency.
Now it's up. the source is the GNU one. which is not an option as I said
before.
It's implemented in 12KLOC which is far more of what I would like to
have inside radare.
it's not that lightweight.. I'm sure this can be reimplemented in less
that 2000LOC
so well...maybe one day I'll get tired of not finding a solution and
will do it for myself.
till then i prefer to have -lmagic instead of storing 500KB of source
files in my repo.
If someone in this list wants to make a suckless implementation of
file(1) i will be happy
to support it and merge it here. I'm sure suckless.org people will be
happy with it too.
the OpenBSD implementation is about 5000LOC IRC.. but it's still too big
imho
Next release will be 0.8.6, and the integration of file(1) inside r2 was
planned before 0.9,
so we are still in time :)
*) It's ok the use of absolute paths. i know there are some hacky things
here because of having to ../ ../.. and ../../.. to find stuff which is
ugly, but I didnt priorize
Cool, I'll put that in first, and it should make the other changes easier.
ok
*) interl-lib dependencies are not properly handled, it would be great
if we could fix this without using automake. any idea here?
How about splitting each r_* lib's Makefile up so that the DEP= lines
are in a separate .mk? Then when make finds r_foo in DEP or BINDEP, it
can
include libr/foo/subdeps.mk
and add all those subdependencies to the list. Repeat until the list
stops growing (that bit may be harder to implement).
If this .mk also contains any -L/-l requirements, then binr.mk could
include each one listed in its current BINDEPS, rather than duplicating
each set of extra flags conditionally.
thats more or less what I thought it will be better. having a makefile
on each
directory with an .mk which offers all the information of dependencies,
libraries, files, etc..
keep in mind
those makefiles have to build:
- libraries
- static plugins
- shared plugins
- test programs
- programs
A lot of the test programs also fail to build in nonPIC mode - some just
need the BINDEPS order changing, some need extra libs. So for the
moment, all I'm testing is that my changes don't break any *more*
things while I'm getting libraries+programs (or standalone programs) to build.
yeah.. having more than one test program is not really well implemented in
the current build framework. In fact we dont currently have a test
framework.
which would be the correct way to implement this, and not building the test
programs unless you type make test.
Another important thing is the inter-lib dependencies. Do you have something
in mind to fix this? Do you know any way to create inter-C-file dependencies
instead of the -MP? And the thing is that a module should run 'make' on all
its deps at each compile try, to find if there's something not yet
build, or requires
to be recompiled because the ABI has just changed (an include file for
example)
This is proprerly handled by automake, but I don't like the bloated
makefiles it
generates and I try always to keep my makefiles small.
We can meet in IRC if you like to talk about it. I can help you in this
refactoring.
Thanks, I'll drop in when I can.
Cya there if you join. (im not there everyday , but just ping me)
--pancake
_______________________________________________
radare mailing list
[email protected]
http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
