Le 17/03/2014 09:12, Valentin Dudouyt a écrit : > Hello Georg, > > Thanks for your suggestion, but I really would like this to be performed > automatically. Perhaps I could even try implementing by myself if nobody > has objections - just need to confirm that this is not possible yet > before posting in -devel. > > Best Regards, > > Valentin >
Hello all, I think what you want can be done efficiently. I'm sensitive to not including unneeded code or data in executable and happened to have experienced that a few months ago. ## Fact I noticed: linker can pick symbols when linking a library I've noticed that sdcc linker brings symbols (and code) at the module level. (Well, at least with sdcc 3.3.0 for the z80 target and modules written in assembly. Please correct me if what follows is only true for some targets.) To be more explicit, breaking down some library into fine-grain modules (the lower limit being one module per symbol) allows the linker to automatically only bring the necessary parts into the resulting executable (even if the compiled library appears as one file). ## We can automate What's the point ? Well, instead of everyone handpicking what they need (manual work, time consumed), it can probably be done once and everyone benefits, whatever the subset needed in their project (optimal result, no manual work). ## How, for one lib To be more explicit, here's what could be done: * once, change the library source code structure so that all independent part are in different modules (it can be in different files). For example, if function A only makes sense if function B is available and vice versa (for example A calls B and B cannot be useful in any way without A), you can keep them in same modules. But you can just skip such analysis and define everything (functions, variables) in separate modules each named like "mylibname_mysymbolname". Then compile the library normally. * from that on, all projects linking with the library (-l mylibname.lib) automagically only bring the code they actually need. This was tested with sdcc 3.3.0 on z80 target. ## Do it once, everyone benefits When some libraries are used by many people it may make sense to do that separation into smaller modules so that all projects from that on benefit. Is anyone aware of any drawback ? (Besides having maps files mentioning many modules from the same .lib, which is okay for me.) Regards, ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
