Fix for CVS build system build issue

[bonkersbobcat]

Edit: I was wrong in my post. It is true that the doxygen stuff is not set up correctly within the automake / autoconf environment for newer versions of the tools, however these problems are not fatal to a build. (The mess of errors this generates was a big red herring.) It turns out that make -f Makefile.dist clean does not do a full clean. Also autoreconf does not cleanup everything either. After completely deleting my showeq directories and re checking them out from cvs, I was able to make -f Makefile.dist all with sucess. You do have to run it twice as there is some subdirectory dependency that is not configured right that causes the first run to fail.

Looks like if you change the version of automake on your system you have to delete the checked out showeq directory structure and let automake build it back up. (Either that or figure out what all the cache and state files that automake uses are, and delete them.) I got it all working with automake 1.9.2, libtool 1.5.6 and autoconf 2.59.

You don't need to use the doxygen patch I have below, if you are having problems: completely delete your source tree, check out the files from cvs, run make -f Makefile.dist twice, and you should be good to go.

The rest of this post is now out of date:

The existing build files do not properly setup current versions of automake / autoconfig to build the doxygen stuff. I haven't had time to figure out why (because I don't know enough about writing automake and autoconfig macros.)

Here is a patch that just comments out the doxygen stuff from the build process. (Doxygen is a documentation build system, so if you don't build the docs, it won't prevent skittles or other seq operation.)

Hopefully someone who understands automake and autoconfig can get proper patches written so that this stuff works, but for now you can apply this patch to turn that stuff off.

BB

[tanner]

On what distro?

Need more info in order to make a fix.

[bonkersbobcat]

FC3 + atrpms update to current:

ayo.freshrpms.net fedora/linux/3/i386 core, updates, tupdates
download.fedoralegacy.org/apt fedora/3/i386 updates
apt.atrpms.net fedora/3/en/i386 at-stable

But I think its any system with automake 1.9.2 or greater.

BB

Edit: included sources.list overview

[cited]

I am gettung this


# make -f Makefile.dist all
Removing old files.......................................... done!
Adding libtool support...................................... done!
Generating aclocal.m4 from configure.in.....................make: *** [aclocal.m4] Fehler 127


So I tried to apply your patch since it seems related to it (I am running mandrake 10.1) but sadly I am getting this


patch -p0 < remove_doxygen.diff
patching file Makefile.am
patching file configure.in
Reversed (or previously applied) patch detected! Assume -R? [n] y
Hunk #2 FAILED at 14.
1 out of 2 hunks FAILED -- saving rejects to file configure.in.rej

on a freshly downloaded cvs version.

Any hints or am I one of those who gona wait for the tar version? :)

[kmkm]

I would make sure you're getting v5 of ShowEQ rather than v4.

[cited]

I did


cvs -d:pserver:[email protected]:/cvsroot/seq co -r pre_5_0_beta showeq

which should get me v5

[kmkm]

Yep - Thought it was worth checking, just incase :)

May as well post the content of Makefile.dist.dbg I guess...

What version of automake does 10.1 come with? This patch only applies to the later versions, 1.9.2 I think.

[I<3EQ]

Some earlier versions, as well. I got no love with automake 1.4p(something, don't remember right now) but 1.7 worked fine.

Anyway, since you're having problems with the removal of doxygen, you can always try updating your automake (if you have no compelling reasons to keep whatever version you currently have) or you can try to figure out why the patch didn't apply cleanly.

If you decide to install a new version of automake, Mandrake 10.1 appears to offer a choice of automake 1.4p6, 1.7, and 1.8 RPMs. I'd suggest removing your current version of automake (rpm -e automake) and getting version 1.7 from http://ftp.sunet.se/pub/os/Linux/distributions/mandrakelinux/official/10.1/i586/media/main/automake1.7-1.7.9-2mdk.noarch.rpm since that version seems to work in Mandrake 10.0, I'd assume the 10.1 RPM will also work.

[cited]

Great thnks a ton .. switching to version 1.7 of automake worked :)

[eqhunter]

redhat have something like automake?

[I<3EQ]

Yes, Redhat has an automake package as well.

You'll need to find a version that works with your version of Redhat and with the seq CVS. Right now, people have had luck with 1.7 and (maybe?) 1.8 -- 1.4 and 1.9.2 are known not to work.

I'd try looking in the update repositories for your version and see if RH has released an updated automake package. If that fails, you'd have to look into installing RPMs from other sources (maybe a newer or older version of RH... though I generally don't recommend that) or maybe building automake from source.

[eqhunter]

can I just do it the old way? and I was wondering if theres a csv for a fresh install



hunter

[bonkersbobcat]

See my edit of the top post of this thread. My doxygen problem was a red herring and the cvs version can be made to build as is with no patch needed.

BB

[gruntsters]

Ok, what exactly does "blow out the whole showeq directory structure" mean ? I deleted my showeq directory and the the .showeq directory. Then I used the cvs download. Trying to run make -f Makefile.dist gets me this


Are you really sure you want to be running this makefile ? (several other sentences along that line too).

hmm, just tried make -f Makefile.dist all (tried this twice in a row)

That gets me this
removing old files......done!
adding libtool support...make: *** [config.guess] Error 127

[purple]

That's a libtool problem. What does Makefile.dist.dbg say?

[gruntsters]

gonna start my own thread so I quit hijacking this one. But I did get further !

in help forum

[fizzleban]

i had to change autoconf/automake/libtool to the following versions:

autoconf-2.59
automake-1.8.5
libtool-1.4.3

[eq0815]

Edit: should read before write, ignore me

[Xman]

I did


cvs -d:pserver:[email protected]:/cvsroot/seq co -r pre_5_0_beta showeq

and I get.


cvs server: cannot find module 'pre_5_0_beta' - ignored
cvs [checkout aborted]: cannot expand modules

I'm new to CVS, i've previously been using tar. Anyone have any ideas?

[eq0815]

I'm new to CVS, i've previously been using tar. Anyone have any ideas? You need to login first, do this:
cvs -z3 -d:pserver:[email protected]:/cvsroot/seq login
cvs -z3 -d:pserver:[email protected]:/cvsroot/seq co -r pre_5_0_beta showeq

[Xman]

I'll give that a try, thanks.

[tanner]

I hate to start a distro troll, but under debian you have it a whole lot easier then Redhat/FC.

Add the following to your /etc/apt/sources.list

deb ftp://ftp.real-time.com/linux/real-time unstable custom
deb-src ftp://ftp.real-time.com/linux/real-time unstable custom

Then, to get all the proper build dependencies and build showeq.

% sudo apt-get build-dep showeq
% sudo apt-get source --compile showeq

I'm sure the gentoo boys are going dazzle us emerge and what not.

My point being, why struggle with Redhat/FC build enviro when alternatives exist. Heck, for my FC box, I just take the debian package, use alien on it, and install it on FC3.

If you insist on Redhat/FC, why not make a virtual package (showeq-build?) with all the appropriate depends, put that up on a private yum archive and help your fellow Redhat/FC people by offering a virtual package they can download that will install all the right tools to build showeq.

Each patch the same cycle happens. Help break the cycle. :-)

[bonkersbobcat]

Each patch the same cycle happens. Help break the cycle. :-)

There are two parts to the cycle. The partial patches that are done by developers to get it sort of working while the rest gets figured out, and the next "release" of the software. I would agree that an easier build system would be nice for the latter (and I think it is in fact happening with some people configuring the various build engines.) But for the former, the partial patches -- that belongs in the developer's domain and does not need to be published beyond these forums. People who are not develpers are welcome to follow along and try and do thier own patching, but I don't think you will find much support for supporting non-devs with the partial releases.

BB

[mudtoe]

I'm still having trouble with the "make -f Makefile.dist all". I do it twice and I get the same response both times:

[root@RHEQ showeq]# make -f Makefile.dist all
Removing old files.......................................... done!
Adding libtool support...................................... done!
Generating aclocal.m4 from configure.in..................... done!
Generating configure headers (config.h.in).................. done!
Generating Makefile.in from Makefile.am.....................make: *** [install-sh] Error 1
[root@RHEQ showeq]# make -f Makefile.dist all
Removing old files.......................................... done!
Generating aclocal.m4 from configure.in..................... done!
Generating configure headers (config.h.in).................. done!
Generating Makefile.in from Makefile.am.....................make: *** [install-sh] Error 1


I'm using QT 3.2 under Red Hat 8

mudtoe

[Tor K'tal]

For some reason Automake isn't picking the right version. The quick fix is to:
#export WANT_AUTOMAKE="1.7"

Then you can rerun make -f Makefile.dist all

How I found this? digging around about automake I found am-wrapper (sometime .sh, sometimes .pl) and while looking inside that file I found that it accepts a user selected version if they user so desires. But ideally it is suppose to autodetect the correct version to use. This problem is also listed in another thread over the last week.

~ TK

[mudtoe]

Tried your export command, same result:


[root@RHEQ showeq]# export WANT_AUTOMAKE="1.7"
[root@RHEQ showeq]# make -f Makefile.dist all
Removing old files.......................................... done!
Generating aclocal.m4 from configure.in..................... done!
Generating configure headers (config.h.in).................. done!
Generating Makefile.in from Makefile.am.....................make: *** [install-sh] Error 1
[root@RHEQ showeq]#

[Leetlewon]

Purple already asked the pertinent question, which was "what does Makefile.dist.dbg say?" - I had this problem and ended up upgrading autoconf, automake, and libtool, getting a fresh cvs then making again and it solved the problem.

[tanner]

Makefile.am.....................make: *** [install-sh] Error 1
[root@RHEQ showeq]#

My guess is you do not have automake installed.

[mudtoe]

Well, I finally got it figured out, at least well enough that it got through the make -f Makefile.dist all, and the ./configure (it's compiling now, so I'm not quite out of the woods yet). The suggestion to look in the Makefile.dist.dbg file was a good one, as it indicated that I had version 1.6.3 of automake and it wanted 1.7. I also had to upgrade autoconf to version 2.59.

The only rant I have concerns this rpm package install business. If the purpose of this stuff is to try to make change management easier so you don't have to be a rocket scientist, they surely failed. RPM sucks as bad as SMP 4 did on the IBM mainframe (I was a mainframe O/S support programmer in a previous life and had to apply patches to MVS). The rpm for autoconf ran just fine and installed cleanly, but the version 1.7.9 rpm of automake for RH8 was just horrible. It said it installed correctly, but I kept getting version 1.6.3 when I did "automake --version". It turns out that the package installer puts the binary executable files "automake" and "aclocal" in /usr/bin as "automake-1.7" and "aclocal-1.7". There were also files called "automake-1.6" and "aclocal-1.6" which were identical to the existing binaries in the directory named just "automake" and "aclocal". I ended up having to manually delete "automake" and "aclocal", and then clone "automake-1.7" and "aclocal-1.7" as "automake" and "aclocal", creating in effect what we used to call an alias name in mainframe lingo. The RPM should have done that automatically, if it was really trying to keep multiple versions of the binary executables in /usr/bin (a very bad practice I might add).

[CeleSEQ]

My point being, why struggle with Redhat/FC build enviro when alternatives exist. Heck, for my FC box, I just take the debian package, use alien on it, and install it on FC3.

If you insist on Redhat/FC, why not make a virtual package (showeq-build?) with all the appropriate depends, put that up on a private yum archive and help your fellow Redhat/FC people by offering a virtual package they can download that will install all the right tools to build showeq.

Each patch the same cycle happens. Help break the cycle. :-)
Yeah, I intend to make a yum repository sometime. However, I do want to point out that in FC1, FC2 and FC3, the current distro versions work fine, no odd version munging is required to build successfully.

The people who have significant problems are always the people running ancient versions. RH9 end of lifed 30Sep2004, but the person complaining here isn't even running that, he's running an even older release, RH8 (widely considered to be one of the buggiest releases, 8.0 was the first RH to include a "corporate desktop" when it was released in Sept 2002.). If someone took an original woody release cd from July 2002 and slapped it on a machine and tried to build from CVS, they'd have some big issues too.

Basically, if someone wants to support these older Redhat releases, more power to them. I pm'd the guy in the help desk forum who was running RH9 to ask him to let me know how my SRPM builds on RH9 (I think it will work, or could be made to work with trivial tweaking). But I'm not willing to spend time on something as old as RH7.x or 8.

RPM does not have the same sort of inherent extended dependency abilities that the apt and ebuild systems do. Yum provides many of those abilities, but honestly, installing yum on RH8 is not fun either. RPM itself has dependencies but no resolution mechanisms. I'll take a look at whether it would be worthwhile for me to build a showeq-devel dummy package, but I don't think that's normally considered good form in RPM... normally I see that done as build-requires dependencies on the SRPM.

[CeleSEQ]

There are two parts to the cycle. The partial patches that are done by developers to get it sort of working while the rest gets figured out, and the next "release" of the software. I would agree that an easier build system would be nice for the latter (and I think it is in fact happening with some people configuring the various build engines.) But for the former, the partial patches -- that belongs in the developer's domain and does not need to be published beyond these forums. People who are not develpers are welcome to follow along and try and do thier own patching, but I don't think you will find much support for supporting non-devs with the partial releases.
Amen. Building from CVS is an unsupported exercise imo. Wait for releases or at least for the packagers.

[Dedpoet]

FWIW, I'm still running RH9 and upgrading autoconf, automake, and libools to the versions in serberus' post (http://www.showeq.net/forums/showthread.php?t=5211) got rid of the build errors for me.

I need to get Gentoo back on this laptop - I miss emerge...

[Cryonic]

The only rant I have concerns this rpm package install business. If the purpose of this stuff is to try to make change management easier so you don't have to be a rocket scientist, they surely failed. RPM sucks as bad as SMP 4 did on the IBM mainframe (I was a mainframe O/S support programmer in a previous life and had to apply patches to MVS). The rpm for autoconf ran just fine and installed cleanly, but the version 1.7.9 rpm of automake for RH8 was just horrible. It said it installed correctly, but I kept getting version 1.6.3 when I did "automake --version". It turns out that the package installer puts the binary executable files "automake" and "aclocal" in /usr/bin as "automake-1.7" and "aclocal-1.7". There were also files called "automake-1.6" and "aclocal-1.6" which were identical to the existing binaries in the directory named just "automake" and "aclocal". I ended up having to manually delete "automake" and "aclocal", and then clone "automake-1.7" and "aclocal-1.7" as "automake" and "aclocal", creating in effect what we used to call an alias name in mainframe lingo. The RPM should have done that automatically, if it was really trying to keep multiple versions of the binary executables in /usr/bin (a very bad practice I might add).

That is normal for RH to deal with multiple versions of certain binaries. What you probably deleted were a bunch of symlinks from the base automake/autoconf to the specific version. I see the same thing for vim, mozilla, qt, etc... Files get placed in specific folders with the version name as part of it and then symlinks are put in place. You could also set aliases for the files before you begin the build to prevent breaking other stuff that might have depended on the older tools.