Off-Topic > SCM EXtensions

SCM Basics

<< < (10/22) > >>

Jason W:
Though I was frustrated with audacity crashing on the preferences tab, I had no trouble making a portable transmission-gtk.tcz in which all the functions seem to work, available in the scm source area as transmission-portable.tar.gz, should work when booting 'base norestore' with only X and a WM running.  I will try my hand at a few and if they are as simple then it is not a bad thing to be able to convert tczs to portable scms.  For one thing, the tczs are already built and there is no duplication of effort when a tcz is converted rather than building from scratch.  Though I intend to compile scm's and keep with that concept and not let it get lost to portability, nothing is lost if we are able to make mountable apps out of stuff in the repo. 

V.Krishn:
The initial concept of scm is ok, I guess If I am not mistaken its one step closer to being portable. Only effort is to make tcz repo re-usable.

vinnie:
I remain alert to every news!

V.Krishn:
I am outlining a probable method for 'scm-built' script.
Still wondering if it would work.

To Build - gtk2.scm
++++++++++++++++++++
Roll the dependencies in one, with current method as eg gtk2.scm, but build directly from tcz package.
Example:
1.Its built by mounting tcz in tmp/cairo and coping or rsyncing it into tmp/gtk2.
2.Like wise all dependencies.
3.Special scripts that runs when scm is loaded can be root or in folder /tmp/gtk2/config.
4.Folder /tmp/gtk2/scm.installed if needed.
Resulting folder structure:
 /usr
 /bin
 /etc
 ...
AND not
 /atk
 /cairo
 ...

To Install
+++++++++++
Mounted in /tmp/scm/nnn.gtk2, where nnn is last new number in /tmp/scm folders for scms.
Symlinks done similar to when installing any tcz, except the path is now to /tmp/scm/ and not /tmp/tcloop.

Symlink Method (Install)
+++++++++++++++++++++++++
1. Dynamically create 2 file, 010.gtk2.scm.list, 010.xgtk2.scm.list in /tmp/scm folder
2. If link present in any other <009.x<packages>.scm.list do not make a symlink but APPEND it to 010.xgtk2.scm.list.
3. If not present in the system already, make symlink and append it to 010.gtk2.scm.list.
4. If present APPEND it to 010.xgtk2.scm.list

Symlink Method (Un-Install)
++++++++++++++++++++++++++++
1. Unlink links in 010.gtk2.scm.list that are not present in >010.x<packages>.scm.list and NOT having keyword /tmp/tcloop in the symlink.
2. Remove 010.gtk2.scm.list, 010.xgtk2.scm.list files
3. Unmount gtk2.scm.

Hope I have not left any steps.

Jason W:
V.Krishn -

It sounds like that method is basically like combining tcz's into one extension, thus eliminating having to call on dependencies, and then linking them into the shared system just like the tcz.

One issue with that is that it would cause library file conflicts since various versions of the same library, built perhaps with different options, would be in /usr/local/lib.  And also the main purpose of the scm is to have a clean mount/unmount that does not install/symlink files into the system, therefore not causing any file or library conflicts.   At least not outside of the .desktop and icon files in /usr/local/share that get linked to the system.

####

Bmarkus in the release candidate thread mentioned the existence of dependencies in the scm's in regards to their effect on the self contained format.  Here is my view, that scm's can be as dependent or not dependent on other extensions that the extension maker deems fit.  I first was including gtk2 into each gtk2 app like leafpad, but that does result in about 7mb of ram being occupied when each different scm gtk2 related app is launched.  And also the time of building gtk2 over and over for each app.  Thus the existence of gtk2.scm and gtk3.scm.  And maybe one day qt4.scm.  To me that is a good middle ground to ease the memory requirement of scm's.  And Xorg-7.6-lib is called on as a dep instead of building parts of Xorg into each extension, though those libs could be placed in the scm's lib/ path to not need that dependency. Up to the extension maker as we already host the source for Xorg.

There is a trade off between total self containment and extension size and resource use.  One can even use the gtk2.tcz and it's deps for an scm dependency, but the more dependencies you add the less benefit of being self contained.  But again, it would be up to each extension maker, there is not a hard and fast rule.   Me, I aim for three or less dependencies to keep it simple - Xorg libs, gtk2/gtk3/qt, and perhaps python or similar.  Smaller stuff gets built into the scm.   

I mentioned about making scm's out of tcz's, and I have done that for avidemux, it needs no deps but either OSS or alsa at the user's choice.  It is basically a test concept that could save a bit of work by using tips from portablelinuxapps.org.  The source is already hosted, no having to rebuild.  There are some snags I have run in to, and I don't know how far I will try to go down that path, but it is kind of neat to play with.  I will of course troubleshoot any issues with the converted scm's, and anyone let me know if they have issue with me making a self contained app out of their build.  But for those apps that convert cleanly and work without issue, it is of great help to be able to use them.

Anyway, not to ramble too much, but that is where things are at now.  I think I am taking a sensible road in regards to structure and dependencies, etc, and I am open to any ideas.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version