Documentation ideas on extensionsForum: myDSL Extensions (deprecated) Topic: Documentation ideas on extensions started by: alfille Posted by alfille on Aug. 15 2005,00:49
I understand that documenting developer features is a thankless task, but still I find myself scrutinizing the website for subtle hints of how to start.The documentation (in the web site) is still not clear. For instance, there are sections on creating uci and tar.gz but none on dsl. Further, the section on uci only talks about modifying an existing uci. In my view, an exposition on creating extensions should be structured along more functional lines: 1. Optimal memory use (uci > tag.gx > dsl) 2. Sections of the file system affected: (opt < opt... < all) 3. How to integrate your appplication into the operating system: A. persistent storage (user.tar.gz) B. shared libraries (wrapper scripts and LD_PROGRAM_PATH) C. desktop icon and menu items D. adding programs to PATH E. kernel modules For instance: I compiled cvs to allow pulling code from sourceforge. As far as I can tell, the only convenient way to package it is as a .dsl so it can be placed in /usr/bin. (Parenthetically, adding /opt/bin to the default path would ease this problem.) I don't want to complain about this elegant system, only bring the fresh insight of a new user to the documentation. And yes, I googled first. Posted by ke4nt1 on Aug. 15 2005,01:50
Nice to see some interest in extension building..I'll assist where I can..
Documentation is currently being revamped. More to come. Stay Tuned.
Both of these topics are heavily discussed in the forum threads.. Search using keywords .uci .tar.gz .dsl Much detail into your items in #3 is also listed and discussed. There is also a .pdf how-to for building extensions in the repository for the budding extension builder. Feel free to submit an addition to this which covers more details about the inner workings, pros&cons, and structure of extension types for more advanced extension builders.
Yes, an /opt/bin would work for single binaries. But more complicated extensions would require that idea to be expanded to /opt/usr/bin, /opt/usr/lib, /opt/usr/share etc... The wrapper is an easy way to be precise about the path your application needs.
allowing you to keep the original pathing structure intact under /opt , just like it would be normally in the root file system .. Please feel free to contribute, submit, or discuss any part of extension building with the DSL userbase, as extensions are always improving and changing to meet the goals of lower ram usage, ease of installing/removing (package mgmt.) and adding more functionality normally found in distros 10-20 times the size of DSL. 73 ke4nt Posted by mikshaw on Aug. 15 2005,02:03
I would be very pleased to learn more about compiling applications with a specified lib path, as with the CPPFLAGS variable. I've done it succesfully only once, and I'm not sure why. This would eliminate the need for a wrapper in many cases.
Posted by ke4nt1 on Aug. 15 2005,02:10
I have only been successful so far by using the ./configure --prefix=/opt/foobar option before running make and make install .. So count me in on any details! 73 ke4nt Posted by alfille on Aug. 15 2005,21:36
The wrapper works very well for graphical programs. I'm having trouble using it in command-line programs since the wrapping program can't be invoked unless it's full path is known. In the case I listed. users would have to remember that "cvs" is called as "/opt/cvs/cvs" or something like that. Since the only issue is having a common place to put the wrapping scripts that is "extension friendly" I thought /opt/bin might be a good candidate. The actual placement within /opt can then be specified by links. Paul Alfille |