On Wed, Oct 22, 2008 at 7:19 AM, Lucas Meneghel Rodrigues <[EMAIL PROTECTED]> wrote: > On Wed, 2008-10-22 at 19:01 +0530, Subrata Modak wrote: >> Cai, >> >> On Wed, 2008-10-22 at 00:42 -0700, CAI Qian wrote: >> > Hi, >> > >> > --- Subrata Modak <[EMAIL PROTECTED]> wrote: >> > >> > > On Tue, 2008-10-21 at 00:53 -0700, CAI Qian wrote: >> > > > Hi, >> > > > >> > > > There are several prerequisites to compile LTP. For example, flex, >> > > > Perl, several C libraries. >> > > > Also, it is easier for distribution to figure out dependences and >> > > > package if we follow this >> > > > standard process. Is autoconf patch welcome here? >> > > >> > > Till now we have resisted introduction of autotools in LTP. Even the RT >> > > tests were re-written to avoid the same. And we had many people not >> > > liking the idea for some reason or the other. Let us know what exactly >> > > you would like to have here. We can then discuss and sort out more. >> > > >> > >> > The problem is just like every project who needs autoconf. There are many >> > dependencies to compile >> > the whole test suite. Without them, the compilation may fail, or generate >> > an incomplete build, or >> > hide potential build errors, or users may report lots of compilation >> > failures due to missing or >> > bad dependencies. With autoconf, it is easier to find out what exactly >> > need to install first >> > without going through a painful debugging process. Although it takes some >> > time to create and >> > maintain autoconf files, it increases the integrity of the project and >> > makes things easier to >> > maintain in long term. >> > >> >> I agree with you in this point. I would also like to hear from others >> what they think about this. Also how Garrett´s Makefiles changes are >> going to affect that. Could you please provide some sample patches for >> this. Let´s discuss this. >> >> Regards-- >> Subrata > > A new build system for LTP would be really great for the reasons Cai > mentioned. Autoconf is something that most developers are used with, but > I personally don't like that much. There are other fairly recent build > systems, such as waf (http://code.google.com/p/waf/) that are very light > on dependencies, are fast and flexible. On my spare time I was working > on a 'minimal' ltp tree, exchanging the makefiles by waf files, was > planning to show when it would be ready for use. > > That said, autoconf is less intrusive on the current workflow of most > developers, since they are already used to it, so it might be a better > option. > > My personal preference is for waf, since with a simple 100K script at > the top directory and waf files instead of make files we can have a > powerful and mostly self contained build environment. But the long time > developers know better what would be best for LTP. > > Best regards, > >> > Cai Qian >> > >> > > Regards-- >> > > Subrata >> > > >> > > > >> > > > Cai Qian
Waf is interesting and with the right amount of Python decorators and Python nose testcase implementation, the build dependency information can become comparable to make. However, here are my questions and points of concern: 1. It's not mature. 2. It's duplicating a lot of similar logic from Python nose unnecessarily, in a not really intuitive way. 3. It doesn't have a comparable set of logic to GNU make's implicit rules, which greatly reduce the make logic -- this is a double-edged sword. 3. Can it reliably setup parallel build processes? My comments about autotools: 1. Autotools, while ubiquitous in the OSS community is a bastardized means of detecting dependencies and modifying source definitions or CFLAGS to meet present or missing dependencies (libtool is a prime culprit of this GNU autohackery that I absolutely loathe because the detection scheme is incomplete and incorrect). There are much better renditions of the same thing which are cross-compilation safe and accomplish the same means to an end. My comments about makefiles (period): Yes, I agree that straight makefiles shouldn't be the ultimate answer to building LTP, because it forces a lot of logic on the LTP developers and maintainers that could instead be used with a smarter build system to accomplish what needs to be done. However, straight makefiles as it stands are incredibly simple and straightforward to understand, whereas complex make systems may or may not meet our needs properly, or may turn out to be too complex or add too much additional overhead for properly solving a problem. The big question I have (for any makesystem) is: 1. Can we easily work with header location changes? Remember, we could set a series of high-level CFLAGS to denote what features need to be enabled and have a global header which is included that properly detects which headers need to included, as well as define whatever macros need to be defined to provide our test API's or API's being tested with the means to compile and link. 2. Can it prune the build to meet the set features so that I -- as a test engineer -- can move from one version of LTP to another WITHOUT the infrastructure telling me that I have to upgrade any components on my target system OR having the build fail on me? Some food for thought. Thanks, -Garrett ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
