Passing cmake variables in a src2pkg script...
 

Gilbert,

I'm posting this here because others may have similar questions.

If I want to pass cmake variables via a src2pkg build script, does it go in the "# EXTRA_CONFIGS=''" line? I need to uncomment that line, right?

This page has the list of configuration options I'd like to use.

Finally, a quick note. I think I found a bug/feature. :)

When I first started to create the src2pkg script (as root), my source file was in a directory path with a space in it. I got this error:

When I moved the source file to a directory without spaces, everything worked fine.

Regards,

-Drew

Drew, srcpkg isn't able to automatically handle extra arguments to cmake. Yours is the first case I've seen where someone wanted to do so -maybe it will be possible to incorporate this in the future.
Meanwhile, you'll need to manually write the configure commands, I'm afraid. Create a starting src2pkg script and then comment the 'configure_source' line and replace it with something like:

The compile_source and fake_install functions should work normally after that.
I'll have a look to see if passing extra args can be worked into the code so this is easier for you next time.

As to the problem with spaces in the path, this was pointed out a long time ago, but has not been fixed yet. Since it is a minor problem, I haven't tried to isolate the spot(s) where src2pkg isn't handling this.

I was out for the morning but when I got back I looked into the src2pkg cmake routines and seem to have gotten EXTRA_CONFIGS working. I don't have the requireds for qgis so you can provide the final test of the changes.

Open the file: /usr/libexec/src2pkg/06-configure_source

You just need to add '$EXTRA_CONFIGS' to lines:
365, 388, 390, 394, 396, 408 and 410

Like this (lines 363 to 413):
As I said, I don't have the requireds for configuration to get very far, but the above changed code seemed to work okay to fix EXTRA_CONFIGS so that you can write it into the script variables, or use it from the command line:
Let me know if that seems to work okay for you and I'll in include it in the next release.

Awesome work, Gilbert. Thanks!

I'll test it and let you know how things work out. We'll get the results of this exercise into the wiki too. :D

I'll test this tonight and post the results.

I'll also add a little bit about the error I got. As long as we document that it happens, I don't think it's a big deal.

Warm regards,

-Drew

Gilbert,

Quick question: my line numbers are two off from yours. That is, your 365 is my 367. That shouldn't be a problem, right? I'm using 1.9.6.

Also, should this line:
Be this (with the curly brackets)?

Thanks,

-Drew

Gilbert,

Here's the relevant part of the src2pkg.auto script:

I'll let you know how it works out.

-Drew

The difference in the line numbers is okay -I have addded a couple of lines somewhere above that lately.
You shouldn't need to supply the prefix with EXTRA_CONFIGS as it is already supplied separately:
EXTRA_CONFIGS='-DQT_QMAKE_EXECUTABLE=/opt/qt4/bin/qmake -DWITH_BINDINGS=TRUE -DWITH_GRASS=true -DGRASSPREFIX=/usr/grass-6.2.3'

Gilbert,

Thanks for the update. I'll modify the src2pkg script and run it tonight. I did the -T test and everything looks okay, but the proof is in the pudding. Unfortunately, it's about a six-hour compile on my computer, so I'm going to start it before going to bed and find out tomorrow how things will have gone.

Regards,

-Drew

Oh, about the curly brackets -it shouldn't make any difference, at this particular spot in the src2pkg code, whether you use or not the curly brackets. I use them, or not, as a means of better formatting which shows up better with syntax highlighting in most editors. I use SciTE for nearly all text-editing because I like the colors and syntax-parser, but whatever you are used to should be fine. The curly-brackets show up differently. I usually use the curly brackets when writing the actual command and arguments which get run. The first $EXTRA_CONFIGS without braces is part of an 'echo' command which shows a prompt similar to this:

Found 'cmake' configuration - Configuring sources using:
cmake -DCMAKE_INSTALL_PREFIX=${PKG_DIR}/${PRE_FIX} -DQT_QMAKE_EXECUTABLE=/opt/qt4/bin/qmake -DWITH_BINDINGS=TRUE -DWITH_GRASS=true -DGRASSPREFIX=/usr/grass-6.2.3

Notice that the above prompt output and the real command use separate arguments for the prefix which are apart from the rest of the configs in EXTRA_CONFIGS -in the same way that is used with other configuration types(autoconf, etc). src2pkg supplies the default prefix and assumes that EXTRA_CONFIGS is empty. The general form looks like this: CONFIG_COMMAND --prefix=PRE_FIX EXTRA_CONFIGS.Occassionaly this arbitrary insertion of the --prefix=PRE_FIX makes some configure scripts choke, but obviously works much more often than not.

"six-hour compile" -Yuck! Just the kind of build to drive you mad when things don't go right or extra unforseen steps are needed to make a really complete package. Good luck!

I've got good news and bad news.

The good news is that it wasn't a six-hour compile -- that must have been QT4 I was remembering. QGIS took about an hour.

The bad news is that even though the package compiled and was created just fine, QGIS won't run. I get this error when I try to run it:

I'm not quite sure how to parse that.

I'm going to try the slacky.eu slackbuild script with the extra cmake options and see what happens. I'm not sure what the script does that src2pkg doesn't do. Here's a link, though, so maybe we can figure it out.

Regards, and stay tuned...

-Drew

P.S. Thanks for clearing up the part about the curly brackets.

Okay, part of the problem seems to be that I've (and the Slacky.eu slackbuild) have got the wrong location for cmake-qt4. The configuration is also saying it can't find GRASS, so I'm going to point right to the GRASS binary.

The new command looks like this:

Or in a src2pkg script:

We'll see how it goes.

Edit: DARN! It still says it can't find GRASS.

-Drew

P.S. I've been home for the past three days with my son, who is ill, and is now napping. So at least I have something to keep me occupied...

:)

Are you running that after installing or from the sources where it was compiled?

From looking at the slackbuild for it, I'd say try putting this in your src2pkg script near the top:

export PATH=$PATH:/opt/qt4/bin
export QTDIR=/opt/qt4
USE_OBJ_DIR=YES

Otherwise, comment out the configure_source, compile_source and fake_install lines and insert this:

export PATH=$PATH:/opt/qt4/bin
export QTDIR=/opt/qt4
mkdir $SRC_DIR/build
cd $SRC_DIR/build
cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/usr -DQT_QMAKE_EXECUTABLE=/opt/qt4/bin/qmake
make install DESTDIR=$PKG_DIR


This syntax '-DCMAKE_INSTALL_PREFIX:PATH=/usr' differs from what src2pkg usually uses: '-DCMAKE_INSTALL_PREFIX=/usr'. I'm not sure if that's part of the problem. Also, the directions in the sources say to run 'cmake .' in the top dir and the slackbuild does the compiling in a separate dir 'build'. USE_OBJ_DIR=YES tells src2pkg to do that automatically for you, but it will be inserting the CMAKE_INSTALL_PREFIX according to the latter syntax above. As always, if it seems harder to convince (or trick) src2pkg into doing what you want, simply comment out the offending lines and replace with very slightly -modified code from a slackbuild or as you would use from the CLI.

Hi Gilbert. I had to go back to work today :( so I'm just now getting back to this project.

If you're referring to finding GRASS, it's when I'm trying to compile from source. GRASS is installed, so I should just be able to point to its directory in the cmake command.

I'm posted in the QGIS help forum, but so far, there's been no answer.

I built from the slackbuild after modifying the cmake line and except for not finding GRASS, everything went well. I did not get the error when trying to run QGIS after installation that I did with the src2pkg-built package.

Okay. I'll try the first option first because I'd still like to be able to pass variables to cmake from the src2pkg script. That part seems to be working pretty well, actually.

What's going on with the $PATH variable above? Is it necessary to point to /opt/qt4 twice? I'm not criticizing, just wondering.

I wonder that too. Does passing the variable to cmake override the usual src2pkg behavior?

I'm not sure I follow (it's been a long day). If I use USE_OBJ_DIR=YES, do it result in '-DCMAKE_INSTALL_PREFIX:PATH=/usr' (what I got from the documentation) or '-DCMAKE_INSTALL_PREFIX=/usr'?

That's part of the beauty of src2pkg -- it's pretty malleable. :D

In terms of finding GRASS, I'm simply frustrated. The documentation for building QGIS is a little confusing because it covers building under Windows, Mac, and Linux, but their Linux instructions are only for Ubuntu. :( I get the feeling that they do most of their work on Windows and/or Mac computers.

HOWEVER, the docs indicate that I also need to compile GDAL with GRASS support. It may be that the GDAL w/ GRASS library is what cmake is looking for.

I'll keep everyone posted.

Regards,

-Drew

Because of this:
qgis: /tmp/qgis-0.10.0-src-1/src/app/qgisapp.cpp:1192:
it seemed to me that maybe you were running the executable from inside the sources or something.

The QGIS wiki lists these dependencies:

libqt4-core libqt4-debug libqt4-gui libqt4-qt3support libqt4-sql
lsb-qt4 qt4-designer qt4-dev-tools qt4-doc qt4-qtconfig
uim-qt gcc libapt-pkg-perl resolvconf

gdal libgdal1 libgeos-dev proj libgdal-doc
libhdf4g libhdf4g-run python libgsl0-dev g++
libjasper libtiff4 subversion
libsqlite3 sqlite3 ccache make libpq-dev flex bison cmake txt2tags
python-qt4 python-qt4-dev python-sip4 sip4 python-sip4-dev

grass libgrass libgdal-1.4.0-grass


Doing these two exports just makes sure that everybody knows where QT is and any other bins located with it like qmake. The 'export' makes the values available to all executables called during configuration, compile and install. All the stuff with -Dsomething is specifically for cmake.
export PATH=$PATH:/opt/qt4/bin
export QTDIR=/opt/qt4

This part is telling cmake (or ccmake, I guess) the same thing
-DQT_QMAKE_EXECUTABLE=/opt/qt4/bin/qmake

I was just looking some more, the best instructions are probably in the INSTALL file included with the sources. It shows using these defines:

cmake -D CMAKE_INSTALL_PREFIX=${HOME}/apps/ \
-D GRASS_INCLUDE_DIR=/user/local/grass-6.3.0/include \
-D GRASS_PREFIX=/user/local/grass-6.3.0 \
-D CMAKE_BUILD_TYPE=Release ..

The thing about the install prefix is this: src2pkg automatically does this for cmake:
-DCMAKE_INSTALL_PREFIX=${PKG_DIR}/${PRE_FIX}
So, giving it again in EXTRA_CONFIGS could cause errors. This makes sure that when 'make install' is run, that the program files get copied into our PKG_DIR properly.
I do not find any reference to using '-DCMAKE_INSTALL_PREFIX:PATH' other than the wiki. It must surely be a typo.

Now, about the OBJ_DIR. using that simply means that the output of the compile process gets put into a 'clean' directory. The clean directory can be inside or outside the source directory. src2pkg normally creates the object dir outside of the sources. For cmake, it is done slightly differently from autoconf sources. Many sources which use cmake assume and direct you to do the build in a clean directory -
assuming you are inside the sources (SRC_DIR):
mkdir -p build
cd build
cmake ..

The 'cmake ..' tells cmake to look for the CMakeLists.txt file one level up -in the main source dir.
To build without using a separate object directory, you'd just cd into the sources and run:
'cmake .' (look for CMakeLists.txt in this directory)

I've just made src2pkg use the native method there -when you specify USE_OBJ_DIR=YES, for cmake configuration the OBJ_DIR used is: $SRC_DIR/build.

I dont find this syntax:

It seems to me that you need a script along these lines:
Since srcpkg supplies the CMAKE_INSTALL_PREFIX, you should something like this when you run the above script.

Gilbert,

As usual, you've been very helpful. I'll give stuff a try and see how it works out.

Regarding the cmake variable INSTALL_PREFIX, check out this page from the cmake wiki. It looks like the "CMAKE_INSTALL_PREFIX:PATH=/usr" is correct.

Regards,

-Drew

Maybe that is specific to newer versions of cmake -I see that the general pattern is shown there for all variables with :something -the something seems to be a variable type specification, BOOL, PATH, STRING. You'll just have to try it both ways till it works.

Hi Gilbert,

I think you're right. The cmake documentation shows a change in the variable syntax in the newer versions.

If I understand how src2pkg works, however, I should be able to modify the cmake portion of the 06-configure_source file to accommodate the new syntax, right?

Again, thank you very much for your help.

Regards,

-Drew

Yeah, just look at lines approx 388-400 in 06-configure_source and change the two
occurrences of:
cmake .. -DCMAKE_INSTALL_PREFIX=/${PKG_DIR}/${PRE_FIX}
to:
cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/${PKG_DIR}/${PRE_FIX}
and the two:
cmake . -DCMAKE_INSTALL_PREFIX=/${PKG_DIR}/${PRE_FIX}
to:
cmake . -DCMAKE_INSTALL_PREFIX:PATH=/${PKG_DIR}/${PRE_FIX}

I'll have to implement a more elegant fix for the next release and check the version of cmake and use the appropriate syntax according to the version found.
Thanks, reporting the results of your research= better src2pkg.

Gilbert,

I'm glad to help. I'm saving this thread with an eye toward getting a lot of this information in the wiki this week.

Regards,

-Drew

Drew, have you been able to tell at what smake ersion those syntax changes started? I need to write a version-detection routine into src2pkg for that, but I haven't seen any direct references to the changes. Thanks for helping out on this one.

Gilbert,

I'm striking out. I've spend the past hour and a half digging through the cmake documentation to find when/if there was a change.

Here's a link to a page with documentation for the released versions of cmake. From what I can tell, this syntax:

...has been around since version 1.8.3. Slackware 12.1 uses cmake 2.4.8.

I hope this helps a little bit.

Regards,

-Drew

Gilbert (and others who are interested),

I finally got the Cmake information into the src2pkg wiki. Check it out here, and let me know what you think.

Regards,

-Drew

Thanks, Drew. Your tip should be outdated and removed from the wiki though with the next release of src2pkg. I had waited to see if any more specific info came out about when the new style of variable was adopted, but when you pointed out that it has been around for quite awile already, I figured that cmake is able to handle the variables using either syntax -since all the stuff I had tested with src2pkg which uses cmake was able to use the old-style syntax. Since that seems to be the case, src2pkg won't even need to detect the cmake version -I'll simply make it use the newer syntax whe it adds the CMAKE_INSTALL_PREFIX by default. This will keep it consistent with the usage for other types of configuration, and when a user needs to add other EXTRA_CONFIGS, they can safely use whatever syntax is suggested by the sources they are building.

Gilbert,

I'll make a note that the 06_configure_source stuff can be taken out when you release the next version of src2pkg. :)

Meanwhile, this should help some people, anyway.

Regards,

-Drew

Thank you, Drew, for following up on this.