I think you need to change the above accordingly:

You need the '=' between '-p' and '/path'.

Take a look at 'src2pkg --help':

LocoMojo

Many thanks I have two scripts now.

John

Thanks for the great software gnashley. I was using checkinstall because I'm new and it was so highly recommended on this board, but then recently I learned it can cause problems. Src2pkg works great. I have to admit though I haven't learned any of its options. Seems to work fine just as it is. I like simple.

Failed again. When I try to use the scripts.

I see a lot of stuff flash up the screen which ends in

How can I direct all output into a text file?

From past failures I know that a cross compiler has to be called.
The Makefile has a line in it like :-

cc=avr-gcc

How can I put this information in the script?
Anything else worth looking at in the Makefile?

John

Okay, first of all: the -X option is used for running a script which you have already created using the -N option. Firts create the script with the -N option and any of the build options which you know you might need, if any. Then, once the script is created you can run it with simply 'src2pkg -X'. You can mix in other of the user options (with capital letters, but not -N or -A). Do not add build options with lowercase letters when using the -X option as they will be ignored and may confuse src2pkg.

For what you are doing you can generate a skeleton script with:
src2pkg -N avr-libc-1.4.7.tar.bz2

Then open the script with your favorite editor and comment the lines:

compile_source
fake_install

like this:

# compile_source
# fake_install

Then write something like this in:

export cc=avr-gcc
export CC=avr-gcc

cd $SRC_DIR ;
make

make DESTDIR=$PKG_DIR install

I think your problems with configure are probably due to using the mixed options as I explained. But if you still get errors when configuring, you may need to comment out that also and run it manually as above for make and make install.
(cd $SRC_DIR && ./configure ....options)

When cross compiling or using other really unusual commands for configure and make it is usually easiest to just comment out the lines and do the steps manually. This still lets you enjoy the benefits of automating all the other steps including temporary file and directory cleanup.

You can run the modified script then with:
src2pkg -X -C -VV (or with more options like -W and -I)

To digger95: glad you like it and that it makes it easy for you to use, even without options (so far).

To LocoMojo: I got your e-mail with the attached changes to the FUNCTIONS file. I haven't had a chance to try it out yet, though it seems that it will work fine without changes. I will consider including such a feature, but as you suggested it would be as an explicit option which could be passed from the command-line, or by inserting in a script or making it the default behaviour by putting it in the src2pkg.conf file. The part about entering a package description was one of the things that I disliked most about checkinstall. In the past removepkg would not work on packages that didn't have a correctly formed slack-desc file, and this meant that you had to put something for all 11 lines of the file during the checkinstall build process. So, I just had src2pkg create a valid file or insert the one you supply (after checking it for validity.) I really mean someday to add code which will parse description text from any description info that is found -like from a .dsc or .txt file used with Slackware, or from an rpm .spec file, debian 'control' file or .lsm file found inside the sources. Reading and formatting the text is not trivial, especially since I want to do it without awk or sed. I do have some scraps of code around for the job though. But I've been quite busy with other projects lately.

Just like to check that last line before I do it

will not try to install it. It is already installed and working and I am trying only to make packages for installation on another computer.


John

Tried everything as far as make but still fails.

I am not using the -A switch now.

Still looks as though I am not engaging the cross-compiler from all the text that flashes before me.

How can I capture the text to a text file so that I can post interesting extracts ?


John

I don't even use src2pkg so much as I use trackinstall that comes bundled with it and I thank you so much for this very program gnashley. Is there any reason why I shouldn't skip on the whole src2pkg and just use trackinstall? If there's no reason, then it's the perfect checkinstall replacement because it does the exact same thing. In my experience trackinstall has worked wonderfully. I say ditch checkinstall and use trackinstall (unless gnashley says not to).

jowa45, this line
make DESTDIR=$PKG_DIR install
should install the program directly to the package tree without overwriting your already installed program. Then the rest of the package build proceeds normally. You have to get the content of the program into the PKG_DIR in order to get a package. The normal way that src2pkg does it (with the 'fake_install' function) is to use installwatch to track what happens when 'make install' is run -without using DESTDIR. Then it copies the files created into the PKG_DIR and creates the package from that.

Either way you must run some sort of 'make install' or you have no content in the package tree. It really is more dependable to not use DESTDIR and let src2pkg track the file and directory creation when directly running 'make install'.

Is your cross-compiler installed into it's own subdirectory or is it, as seems, installed into your regular path and uses binaries with the 'avr-' prefix? I think you'd get better results by compiling your cross compiler to reside in it's own directory (like /usr/avr-gvv or /opt/avr-gcc). Then create a wrapper for it that you put in your normal path. This avoids lots of problems.

For an example of how to do this, see my build for gcc-3.4.6 here:
http://distro.ibiblio.org/pub/linux/...vel/gcc-3.4.6/

You say that you have already compiled and installed your program manually. What commands did you use to configure, compile and install it?


Inuit-Uprising: there is no reason to not use trackinstall if it does what you want. The reason I recommend using src2pkg is that it encourages you to use a script -which means you have a record of any configuration options which you have used before compiling the software. If you are compiling using the simple './configure --prefix=/usr && make && make install' then there is no special information to save as this is the default that src2pkg uses. Using src2pkg from start to finish also makes it much faster and easier to repeat the build since it takes care of all the cleanup operations. There are cases where trackinstall may be preferable -like when a user insists on configuring and compiling while logged in a s a normal user. Then you can just su to root and run trackinstall to create the package. Also, trackinstall is better at creating packages from programs which install by running some sort of script like: 'sh install.sh'. In that case a simple 'srcpkg -S' suffices. If the script is name something besides 'install.sh', you just use the -i='' option to pass the command used to run the installation. This even works with installers that run interactively and ask you where to install stuff.
I rarely use trackinstall myself and sometimes worry that bugs or glitches might creep in from changes I make to the FUNCTIONS which affect both src2pkg and trackinstall. So, I'd appreciate it if you let me know quickly if you have trouble with using trackinstall.
Please note that tarckinstall can also create and use scripts -they are called *.TrackBuild scripts. These are useful if you need to add commands to 'massage' the package content in any way, like adding extra documents or whatever.

I will try to explain a little more fully. Yes I have a source code installation of the tool chain. It was installed on Slackware 11 just after that came and has been in daily use since with little problem. Then earlier this year I saw a post " The Magic Package Maker comes of Age " when src2pkg was introduced. After a lot of help I achieved packages for all members of the tool chain except the library files.
When I came to use these packages on other computers with first Slackware 11 and then 12 they work fine. I can install the tool chain even on minimal Slackware installations which have nothing from Slackware D or L by installing first the packages that I do have and then installing the library files from source. It works because the cross compiler installed from package is called which I imagine then looks for files only in the other installed members of the tool chain.

To install from source code

Works fine.

With all installations I have put /usr/local/avr/bin in path even before beginning tool chain installation.

With the advent of src2pkg1.6 I have returned to the idea of making a package due to the success of the packages I did achieve. I would like firstly a script with the -N switch so before I get too confused lets just start again and get a script first and when I see what it looks like we can consider editing it.

John

Hmm... src2pkg needs a website.

Why does src2pkg require root priveleges to run?

Also, it seems to fail if the source tar ball is in a path which has spaces in between...

other than that , I like this very much.

Many programs don't do well with spaces in file or path names, so src2pkg is no exception there. I haven't had the problem myself, nor have I had reports of it before so I hadn't thought about it. I'll see what can be done about that.
src2pkg requires you to be root because it actually runs 'make install' during the process of package creation. While there are methods to build packages without being root, they are not foolproof. Being root insures that all permissions are correctly set when the package is made, so that the package can be installed and run by any user, the same as any official Slackware package. Note that you must also be root to build packages using SlackBuild scripts in order for perms and ownership to be correctly set.

Hey gnashley,

I submitted my review of src2pkg 1.6 to Linux.com last night. I'll post here when it is published. :-D

Overall I was very impressed with your program and I'm glad I took the time to begin learning how to use it.

I've still got some questions, but I'm beginning to see how I might figure out the answers. For instance, looking at the SlackBuild from Slackbuilds.org for Open Office one sees the following comments indicating corrections to the package to optimize it for Slackware:

I'm not sure how to accomplish those tasks using src2pkg, but I suspect using a src2pkg script or a do_install.sh script running after the installation is the way to go.

I actually did not build OpenOffice 2.3 for my review. But I did build Emacs 22.1, Scribus, Opera, and I converted an RPM for a game called Orbit.

My one piece of constructive criticism is that the documentation, while well-written and informative, is spread out over too many files. I feel it would be helpful if they were consolidated into a single info or man file.

Regards,

-Drew

Those fixups can be fairly easily done by a patch or (as you said) in a src2pkg script, probably some extra commands right after fake_install.