Search Members Help

» Welcome Guest
[ Log In :: Register ]

Mini-ITX Boards Sale, Fanless BareBones Mini-ITX, Bootable 1G DSL USBs, 533MHz Fanless PC <-- SALE $200 each!
Get The Official Damn Small Linux Book. DSL Market , Great VPS hosting provided by Tektonic
 

[ Track this topic :: Email this topic :: Print this topic ]

reply to topic new topic new poll
Topic: Documentation ideas on extensions, A better way to organize the information< Next Oldest | Next Newest >
alfille Offline





Group: Members
Posts: 20
Joined: July 2005
Posted: Aug. 15 2005,00:49 QUOTE

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.
Back to top
Profile PM 
ke4nt1 Offline





Group: Members
Posts: 2329
Joined: Oct. 2003
Posted: Aug. 15 2005,01:50 QUOTE

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
Back to top
Profile PM 
mikshaw Offline





Group: Members
Posts: 4856
Joined: July 2004
Posted: Aug. 15 2005,02:03 QUOTE

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.

--------------
http://www.tldp.org/LDP/intro-linux/html/index.html
Back to top
Profile PM WEB 
ke4nt1 Offline





Group: Members
Posts: 2329
Joined: Oct. 2003
Posted: Aug. 15 2005,02:10 QUOTE

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
Back to top
Profile PM 
alfille Offline





Group: Members
Posts: 20
Joined: July 2005
Posted: Aug. 15 2005,21:36 QUOTE

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
Back to top
Profile PM 
4 replies since Aug. 15 2005,00:49 < Next Oldest | Next Newest >

[ Track this topic :: Email this topic :: Print this topic ]

 
reply to topic new topic new poll
Quick Reply: Documentation ideas on extensions

Do you wish to enable your signature for this post?
Do you wish to enable emoticons for this post?
Track this topic
View All Emoticons
View iB Code