Easy and fast way to create or update extensions

[Jakob Bysewski]

After creating some more extensions today I wondered if I could manage to make the process of creating an extension from source easier and more feasible.
I created a makefile based approach which I want to share with you.

I attached an Makefile to include - and an example file to see it's use (sox.mk).
All you have to do, to get an extension is write down 5 lines of configuration like this (from sox.mk):

Code: [Select]

EXT=sox
VERSION=14.3.1
SITE=http://sourceforge.net/projects/sox/files/sox/$(VERSION)/
CONFIG=--prefix=/usr/local --with-distro="Tiny Core Linux" --with-dyn-default
TCEs=libid3tag libid3tag-dev libvorbis-dev libao-dev libsndfile-dev flac-dev wavpack wavpack-dev libtool-dev libltdl alsa-dev

include make_tc_extension.mk

Here I configure the name of the extension, the current version, an url to download from, configure options and extensions needed to compile. On the last line I include the helper makefile, where all the magic happens.

When I run

Code: [Select]

make -f sox.mk
it will download and load the needed extensions, download, extract and configure the source in a folder named after the extension to create (here sox), make, make install into sox/package and download the current sox.tcz.info file and update version and size in it.
Then I can update the changelog in the info file and the dep file and then issue

Code: [Select]

make -f sox.mk crypt
which will create an archive containing *.tcz* and crypt it afterwards.

If I'll do this for a package new to tc, I'll get a stub info file, will fill in the information, create the dep file and I'm done too.
In depth documentation is in the make_tc_extension.mk file which is pretty straight forward I think.
It is possible to run single steps seperated, e.g. configure to get the right options by

Code: [Select]

make -f sox.mk configure

I wondered whether it would be usefull to create such files for every extension when it's created or updated. That way build dependencies and source locations would not only be documented but also runnable. In most cases an update would only need a change in the VERSION and a rebuild, which is easy to do.
Try it and let me here your criticism  
Maybe this idea can be further enhanced?

Edit:

• 2010/12/31 Fixed small error in creating an infofile when none existed which didn't work
• 2011/01/01 Added an alternative install option for packages not supporting DESTDIR, removed quiet from make
• 2011/01/01 Corrected bad else block

Feature ideas:

• Automatic sepration of locale and documentation data into separate extensions
• Automatic inclusion of icon and menu entry (how to get them from existent extensions? Maybe save the source images in the repository?)

[vinnie]

I prove your script but don't work  

In order:
1) install compiletc package on tinycore
2) Install dependencies of compiling (SDL-dev for circuslinux)
3) download you 2 scripts and edit sox in circuslinux.mk like this

Code: [Select]

EXT=circuslinux
VERSION=1.0.3
SITE=ftp://ftp.tuxpaint.org/unix/x/circus-linux/src/
CONFIG=--prefix=/usr/local --with-distro="Tiny Core Linux" --with-dyn-default
TCEs=SDL-dev

include make_tc_extension.mk
4) downoad and extract work but i receive this error
http://nopaste.voric.com/paste.php?f=qiap4z

Normal compiling of the software work correctly, would know to find the error?
Thanks

[Jakob Bysewski]

You just transfered the CONFIG but besides prefix nothing is needed - with-distro and with-dyn-default were needed for sox.  

I could reproduce your build errors but fix them by adding SDL, SDL_gfx and SDL_gfx-dev to the TCEs and not only SDL-dev. I cannot understand how you were able to build outside my script in the first place as it does no "real magic" at all - it just calls configure and make. It also sets the following recommended flags, maybe these were interfering?

Code: [Select]

CFLAGS=-march=i486 -mtune=i686 -Os -pipe
CXXFLAGS=-march=i486 -mtune=i686 -Os -pipe
LDFLAGS=-Wl,-O1

There remains one problem which seems the main one: circuslinx does not understand DESTDIR, so the standard approach

Code: [Select]

make DESTDIR=package install
doesn't work.

[Jakob Bysewski]

I updated make_tc_extension.mk for supporting packages which don't understand DESTDIR and will attach my working circuslinux.mk file here for you to try.

Code: [Select]

EXT=circuslinux
VERSION=1.0.3
SITE=ftp://ftp.tuxpaint.org/unix/x/circus-linux/src/
CONFIG=--prefix=/usr/local
TCEs=SDL SDL-dev SDL_gfx SDL_gfx-dev
PREFIX_INSTALL=y

include make_tc_extension.mk


[vinnie]

Ok Work! but mksquashfs (squashfs-tools-4.x.tcz) is necessary in addition to compiletc to create a package! otherwise i receive this error http://pastebin.ca/2036585
But software do not create a .dep file, and install type "local" on appBrowser don't install dependencies (sdl).

If this program succeded to be omnicomprensive, it would be great to become a tool to create package with fltk interface!

[Jakob Bysewski]

Yeah, squashfs is needed, too.

The *.dep file is to be created by the user, as it's content is not to be guessed easily. Do you have a proposal for automating this? We could seperate TCEs into TCEbuild and TCErun and then generate the *.dep from that.

What do you want to do with a fltk program? Currently I thought of this Makefile to help developers and packagers create extensions and to track the build of extensions for easy rebuild or update. As these things often need you to get your hands "dirty" (-> do some configuration or testing on the console) I have not thought about a graphical interface. The only thing I can think of currently is the creation of the *.info file, but for this task every text editor will be sufficient.
But if there would be a demand, this is certainly possible. Another possibility would be to automatically invoke a text editor,

Are there any other opinions to this prototype / idea?
Could this be interesting to the tc lead or the extension creaters in the community?
What other features would you like to have or which would make you use it?
As I have seen some have downloaded the Makefile without any comment  

[maro]

Quick question: How do you suggest to handle the split-up of the build result into multiple extensions?

For example to keep with the general intention of TC very often the documention gets seperated into a 'EXT-doc.tcz', likewise for 'EXT-locale.tcz' or 'EXT-dev.tcz.

[vinnie]

ok, you're right, I was  too excited  
However thought  TCES related only to the  build dependencies and not to the starting dependencies (This is why  I wrote only SDL-dev, in teory SDL_gfx is not necessary whereas what INSTALL.txt says).
I think it's a good idea to separate them, there is also more clearly.

For the fact  that there are no feedback, perhaps  in the forum are all professional users, but for people like me this makefile is a good thing  

[Jakob Bysewski]

@maro:
This is something to think about in depth but I think it'll be needed if this process of creating extensions should be widely adapted.
It think it should be possible to specify subfolders as variables which then could be automatically seperated - e.g. DOC_DIR=/usr/local/share/doc/EXTNAME/
As this is similar for most packages one could make defaults which would only have to be changed for some packages.

My goal is to make building extensions feasible (so that everyone can make a new extension when he/she wants a specific package without even knowing in detail how to compile from source), easy to maintain and maybe even fully automated - last but definitivly not least the extensions built with this method should stand all tc requirements and fullfill them out of the box.

What do you think about this approach? I'll try to get to this tomorrow.

@vinnie:

However thought  TCES related only to the  build dependencies and not to the starting dependencies.

Uhm, I think I have chosen the wrong formulation - these are in deed only the build dependencies and no *.dep file is created automatically.

[vinnie]

uhm, in teory for circuslinux  should be enough the sdl-dev dependence.
Sdl need it only to start..

[Jakob Bysewski]

I thought so too, but needed these extensions to make it compile  - without I had the same errors about missing symbols like you,

[vinnie]

Ok, i try again.
The latest two package sdl gfx is unnecessary for compiling and starting application, but SDL.tcz it is essential as you say.

Other proposal, make it possible  to include an icon and a menu entry

[curaga]

How would one link against a lib that doesn't exist? [retoric question]

[Jakob Bysewski]

Exactly 

[b1ackmai1er]

Hi Jacob,

In your initial post the command line appears wrong ... I think

says: mage

should be: make

Regards Phil