Hi,

I was trying to use src2pkg to compile avidemux2, but ran into a problem and I don't know what to do.

Basically the problem is (I think) that before running "configure" you need to run "make -f Makefile.dist". I don't know how to get it to do that.

It also seems to think the sources are "rpm2tgz" format, but they are definitely source code.

Any help would be appreciated.

Thanks,
Brian

I know that src2pkg allows you to specify additional arguments for "make" and "configure", but I don't think there is any option to prefix those commands with another command entirely. Likewise, there is support for giving src2pkg a custom installation script, but that wouldn't be run until after it has already been compiled...

gnashley (the author) is fairly active on the forums though, and will certainly be able to advise you on the issue.

Incidentally, situations like this one are one of the main reasons I could never start using src2pkg as a serious tool on my system. How can I know which arguments to give configure, or if there are any special build requirements, without decompressing the source tarball? If I have already decompressed the source, then one of the main advantages of src2pkg is already out the window. I just never really understood the logic of it; perhaps I am missing something.

Not that writing slackbuilds really alleviates the issue, but at least there I have direct control over the build process and can adjust it accordingly.

Let me also ask a different src2pkg question: is there a way to use src2pkg to create a slackware tgz for source code that is already compiled (ie. like you would use checkinstall)?

Brian

BCarey: For the first problem, the easiest way is to first have src2pkg generate a script for using the -N option. Then open it with your favorite editor and insert the needed line between fix_source_perms and configure_source, like this

fix_source_perms
cd $SRC_DIR && make -f Makefile.dist
configure_source

Don't worry about it incorrectly guessing that it's a rpm2tgz format. src2pkg doesn't do anything special there anyway. That's a glitch in a routine that used to work more accurately. I just noticed the other day that it was falsely reporting that sometimes and have meant to simply remove the prompt as src2pkg is just trying to brag about how smart it is anyway :-).

As for the second question, src2pkg includes the trackinstall program which works mostly the same as checkinstall for sources you have compiled. Or if it's a pre-compiled binary with an installer script you can do that also by using trackinstall -S -i='installer-script-command'

MS3FGX, while src2pkg can very often produce a proper package on the first try, I don't expect you to automatically trust, use or distribute the package it produces the first time. You should always examine the contents of the uncompressed PKG_DIR and any doinst.sh script which is produced for accuracy. Quite often the *perfect* will require an extra rule or line of extra code(like adding an xinitrc file, etc).
Also, you'll usually want to edit the slack-desc file which gets generated(unless you already created one before running src2pkg). I usually start a build by running
src2pkg -N tarball-name (this just creates a script and new.slack-desc without doing anything else.
Then I start the first build by running 'srcpkg -X' which just executes script.
Then, while it is building I go in and open the README .spec or control file and pull the text I want for the slack-desc file and put it in there and then change the name of it to just slack-desc. (The naming scheme keeps any slack-desc file from getting clobbered. If you run src2pkg -N or -A, the new.slack-desc gets rewritten each time).
Usually there is enough time to edit and rename the new.slack-desc file before src2pkg gets to the point of inserting the file into the PKG_DIR, so it can be included in the first build.
Either way, when src2pkg has finished the first build you can take your time to look into the PKG_DIR and/or SRC_DIR to see whether the build has succeeded in doing everything you want or expect. If not, lines can be easily added to the script.
You can then re-run the build and use the -W option to remove the temporary files and dirs.
I highly encourage you to always check the package content and re-run the build after any changes. This is only annoying when the compile takes a long time.

The default build which src2pkg carries out is normally based on the generic commands ./configure, make, make install. Obvoiously this doesn't work for all sources and src2pkg can certainly *not* interpret the README file to figure out some weird directions that might be there, or know that you need to pass '--enable-hellfire-and-brimstone' to get it to compile. (I do still have plans to make it read the configure line from any included .spec file and try those options if you have not given any configure options and the build has failed) This sort of interpretation is pretty far-out and hence low-priority.

src2pkg is very flexible. If you can't figure out how to get the built-in routines to do what you want, just comment them out and insert the needed lines of code. This still saves you *lots* of lines of coding and the only variables you need to know about usually are CWD, SRC_DIR and PKG_DIR. I quite often comment out one or all of the configure_source, compile_source and fake_install lines and insert lines there. Also, many, many packages need manual code to repair operations which are incorrectly done by the Makefile, or to add special content which the sources, or you, provide. Usually even complex changes can be coded with just a few lines and you can still take advantage of the automatic features for the rest of the build. Each of the src2pkg functions is designed to be independent to make this possible.

Thanks, gnashley, that seems to be working (its compiling now).

Brian