I have finally decided to import file(1) from openbsd. I have refactorized thr code and now its 6000 loc instead of 8000. Quite acceptable.
Now libmagic dependency has been removed. I have also added some scripts in sys/ to help to maintain the r2 installation fine. On 09/09/2011, at 18:32, pancake <[email protected]> wrote: > 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 > _______________________________________________ radare mailing list [email protected] http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
