trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: September 2010

Re: [trinity-devel] Building kdebase with svn 1173506

From: Darrell Anderson <humanreadable@...>
Date: Thu, 9 Sep 2010 16:52:31 -0700 (PDT)
> Not easily it would seem.  If this keeps up I will
> need to install
> Slackware on a VM here, but that will take a few days when
> downloads are
> included and also would require me to have a current copy
> of your build
> script(s).

My local rsync scripts are heavily modified for local usage, but are based on these original scripts:

http://connie.slackware.com/~alien/tools/rsync_current.sh

http://connie.slackware.com/~alien/tools/rsync_slackware_patches.sh

Those two scripts, modified for your QuickBuild system, should help you sync any Slackware mirror.

I would expect you to hold off for a bit yet as long as I am still here doing the grunt work. :) But eventually you'll need something like those scripts to keep the sources synced.

Regarding my build scripts I think I now have them written to support fully automated runs. Of course, I won't know this for certain until we know that all the (main) packages build without errors. :) When we get that far I plan to run several tests.

I can send you copies now, but I am likely to modify them again. We still have several main packages to go and with each new package that I try to build, seems I need to tweak the entire process just a bit.

The original Slackware build scripts were noticeably generic and did the job, but we no longer are dealing with generic stock KDE sources. I also am trying to think ahead for other Slackers and build versatile and robust scripts for them. For example, some people will want to build from svn and some from source tarballs. When you go live with Slackware support, those build scripts should be flexible for many kinds of Slackware users and not just me. :)

> Generally what I do is look for a class name at the failing
> line number,
> then search the entire Trinity source directory for
> <classname>::<classname>, where
> <classname> is the class name you found
> referenced in the failing file.  When I find it, I
> look for a .h header
> file with the same name, then include that in the failing
> file.

Noted! Thanks.

Is there a pecking order in which include files must be listed in the declarations? Or is including those files similar to sourcing files in shell scripts and the order is (most of the time) unimportant?