A couple of questions about extension building

[dmoerner]

Hi, I'm interested in working on creating extensions for TinyCoreLinux (wpasupplicant and rt2860 module for the kernel).  I was curious if someone could clarify how to make extensions.  I will stay with .tce extensions here because of the tce2tcz.sh script.

1) The extensions look like g'zipped tarbombs that mostly install into /usr/local, with the exception of core libraries installing into /lib and the kernel headers shipping with symlinks in other directories.  The compiletc.tce extension also seems to move beyond /usr/local.  Is there some clear distinction between packages in this regard?  Should all user-contributed extensions go into /usr/local?

2) I also find this confusing because sources like http://tinycorelinux.com/files/extensions/src/wireless_tools/compile_wireless_tools say that make install should be modified to install into /usr, and not /usr/local.  However, the wireless_tools package contains everything in /usr/local.  Is this just an outdated information file, or do you use some dedicated build tool to create the .tce from files installed into /usr?

3) In /usr/local/tce.icons/$package, what is the difference between t: $package and c: $package?  Does one refer to the package and another to the actual binary?

4) Sources like http://tinycorelinux.com/files/extensions/src/Xorg-7.4/TC-script again suggest that the .tce packages are built using some sort of quilt-esque system that sees what is installed in / and then makes the tarball from there.  How is this done?  How do you keep track of the files that Xorg, for instance, installs in /, so the tarball can be made.

I apologize if some of these questions are really simplistic--I might be missing something obvious.

Thanks for all of your work!

By the way, you should probably put the irc channel on freenode on the main webpage.

[^thehatsrule^]

1) Yes, /usr/local is the target prefix.  compiletc is outside of it because it was probably built before this and would take a lot of time to reconstruct, and can allow for easier extension making (since it won't clutter /usr/local)

2) probably was updated and that file was forgotten about..  See the .info

3) icons are of wbar spec. t: title, c: command

4) not sure what you mean by "suggest that ..." - it can be something like my point in 1) or you could use a date marker such as

Code: [Select]

touch /tmp/mark; INSTALL; find /usr/local -newer /tmp/mark -not -type d > new_files.list; less new_files.list
last) already pushed for

[dmoerner]

4) not sure what you mean by "suggest that ..." - it can be something like my point in 1) or you could use a date marker such as

Code: [Select]

touch /tmp/mark; INSTALL; find /usr/local -newer /tmp/mark -not -type d > new_files.list; less new_files.list
last) already pushed for

Sorry, I was a bit unclear on that last point.  I meant that since there is already a script written to build the package, the fact that the script didn't include the final tar command seemed to suggest that another, unspecified script was doing the building.  However, your comment cleans this up a lot.  That find command looks very useful since you can just pump that straight to a tar.  Thanks for the tip.

This looks like a very simple system. I will try my hand at some packaging soon.  I'm already impressed that compiletc and the headers successfully compiled rt2860, which is known to have an awful code base.

[Juanito]

The extensions should be gzipped tarballs in /usr/local unless there is some particular reason why this cannot be done.

I made the compile_wireless_tools file right at the very beginning of tinycore and forgot to update the file after I re-compiled the extension to /usr/local.

The compiletc extension is an exception in that it works better from /usr so I did not re-compile it to /usr/local. There is a compiletc.tcz extension that will use much less ram.

[softwaregurl]

Everything here is going over my head i guess. I've tryed a few times to compile something but never succeeded and I'm spoiled now with extentions and aptget.  I saw some talk about maybe using debian or other repositories.  Did that ever happen?  I need apache and some additional PERL modules.  A n00b step by step to compiling would be very helpful right now.   

Thanks

[Juanito]

I'm travelling at the moment, so I don't have the time to explain fully - as a start, you can read the "beyond linux from scratch" instructions for compiling perl modules and they will compile without problems on tinycore if you have the compiletc and perl_xml extensions loaded

[softwaregurl]

Thanks Juanito. This would be the best link I found.
http://www.linuxfromscratch.org/blfs/read.html

[Juanito]

You need http://www.linuxfromscratch.org/blfs/view/stable/general/perl-modules.html

[curaga]

Xorg is a special case, if you want to use something from it's script please only use the CFLAGS/CXXFLAGS

In general I usually use --prefix=/usr/local but add DESTDIR=/tmp/XXX to make install, to have it generate the pack in /tmp/XXX/usr/local, it's easier to tar from there.

With Xorg all packages depended on each other, so they were copied to the base system after installation to /tmp/something to enable building the next part.

[^thehatsrule^]

Now I get what the original question meant, I think.

curaga: is DESTDIR supported in most makefiles?  Or is it a hit and miss thing like install-strip?  I've only used it once or twice for packages that did not include a configure script, iirc.

[curaga]

It's pretty widely supported - all autoconf-based ones and most self-written ones (Mplayer comes to mind) should support DESTDIR in the install phase.

[mikshaw]

I had wondered what that variable was....so it lets you configure the prefix to a specific directory, yet the files are actually teporarily installed into another directory, so it makes packaging something to install into prefix very easy?

Always learning something new =o)

[curaga]

Exactly

[mikshaw]

I tried this with Vim yesterday.  Using the compile tcz extension only, I built Vim and installed it into the system as normal to see that the program works, then did "DESTDIR=/path/to/dir make install" to install a second copy to a separate location.  That's sweet.

[Jason W]

DESTDIR is supported in over 95% of programs, and virtually all of the newer ones.  On some occasion there are some tweaks that have to be done when using this option, but mostly just in the case of older stuff.  For instance gdk-pixbuf has to also have it's .la files adjusted when using the DESTDIR option as the library path in those files gets set to -L$DESTDIR/usr/local/lib rather than -L/usr/local/lib.  That is not often though, and is pretty much a makefile writing error. 
There are some other ways used to get the same result depending on the makefile, such as "make prefix="pathtodir/usr/local install".  Or "make install INSTALL_ROOT=pathtodir".  Arch and Crux always install to a dedicated directory when making and packaging a program, and their build scripts give some good clues as to what method is to be used.  Same with Slackware. I often look to their methods for building and packaging guidance.