myDSL Extensions (deprecated) :: Documentation ideas on extensions



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.
Nice to see some interest in extension building..
I'll assist where I can..

Quote
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.


Documentation is currently being revamped.  More to come.  Stay Tuned.

Quote
1. Optimal memory use (uci > tag.gx > dsl)
2. Sections of the file system affected: (opt < opt... < all)


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.

Quote
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.)


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.
Quote
export PATH=/opt/foobar/usr/share:$PATH
export LD_LIBRARY_PATH=/opt/foobar/usr/lib:$LD_LIBRARY_PATH

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
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.
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
Quote (ke4nt1 @ Aug. 14 2005,21:50)
The wrapper is an easy way to be precise about the path your application needs.
export PATH=/opt/foobar/usr/share:$PATH
export LD_LIBRARY_PATH=/opt/foobar/usr/lib:$LD_LIBRARY_PATH
allowing you to keep the original pathing structure intact under /opt ,
just like it would be normally in the root file system ..



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
Next Page...
original here.