Documentation ideas on extensions
Forum: myDSL Extensions (deprecated)
Topic: Documentation ideas on extensions
started by: alfille
Posted by alfille on Aug. 15 2005,00:49I 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:50Nice 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.
Posted by mikshaw on Aug. 15 2005,02:03I 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:10I have only been successful so far by using the
option before running make and make install ..
So count me in on any details!
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.