ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltib] Fix + Optimization when checking for updated source


From: Jehan Bing
Subject: Re: [Ltib] Fix + Optimization when checking for updated source
Date: Thu, 22 Mar 2012 11:06:56 -0700
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0

Indeed we could use the builddir/buildsubdir variables, that just slipped my mind.

We used to have the packages directly in rpm/BUILD but we recently refactored our scm with one empty super-project and lots of sub-projects (package1, package2, ltib) at the root of the super-project. And the straightforward, minimal fix was to just symlink the new location to the old one.

Symlinks seems slightly cleaner though because then the spec file doesn't depend on our scm setup. Hmmm, maybe I'll add a "SCM_ROOT_DIR" var as a ltib config, that's probably even better.

That said, symlinks worked fine so far with the exception of detecting the updated source. Maybe it causes issues on some cases but we haven't hit any so far.


Another thing we are thinking of using symlinks for is to force a package rebuild when a static library is rebuilt. Right now, if package1 builds a static library and package2 depends it, when package1 is updated, package2 is not. If "find" follows symlinks, we could just symlink the static lib in the package2 directory and that would trigger the rebuild.
Maybe you have a better solution to that problem?


        Jehan

On 2012-03-22 02:21, Stuart Hughes wrote:
Hi Jehan,

I think the -quit is definitely something to add.

As far as the other stuff goes, I see what you're trying to do, but I
wonder what your scenario is?
With the exception of the kernel, I would not expect symlinks in
rpm/BUILD. If you want to have packages outside the build area, the
normal mechanism is to use the 'directory build' method, this allows you
to independently manage the source tree (e.g. svn, git, cvs). For an
example see:
dist/lfs-5.1/dtc/dtc-dir-build.spec.in
config/userspace/dtc.lkc

The concern I have with this approach for normal packages is that not
all operations will work correctly. It's been a while since I've looked
at this in-depth, so I can't recall all the issues.

I'm not saying no to this, but I'd like to understand a little more
about what you're trying to achieve by having symlinked packages.

Regards, Stuart

On 22/03/12 01:09, Jehan Bing wrote:
Hi


Our ltib setup is currently this:
package1/
package2/
ltib/
rpm/
BUILD/
package1 -> ../../../package1
package2 -> ../../../package2

because rpm/BUILD/packageX is a symbolic link, "find" returns
immediately when checking if the source was changed and doesn't
actually check the source. One option is to add a / at the end of the
directory name ("find $src_dir/ ..."). But there could also be
symlinks inside the directory pointing outside tree so I think use
"-L" to follow _all_ symlinks is a better idea (though it can slow
down the check quite a bit if the symlink points to a big directory)

Also, find will search for _all_ the files that are newer than the rpm
but knowing that one file at least changed is enough and checking the
rest is just useless processing. So find should use the "-quit"
parameter to stop the search as soon as one file is found.

Patch attached.

Cheers,
Jehan


diff --git a/ltib b/ltib
index 10134a7..9f66282 100755
--- a/ltib
+++ b/ltib
@@ -904,7 +904,7 @@ TXT
die("'$src_dir' doesn't exist\n") unless -e $src_dir;
}
# See if the source tree has been touched
- $cmd = "find $src_dir -newer $rpms[0] -print";
+ $cmd = "find -L $src_dir -newer $rpms[0] -print -quit";
print "checking if sources have been updated: ";
if(`$cmd`) {
print "yes\n";



_______________________________________________
LTIB home page: http://ltib.org

Ltib mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/ltib







reply via email to

[Prev in Thread] Current Thread [Next in Thread]