Hi, --- Garrett Cooper <[EMAIL PROTECTED]> wrote:
> 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? > Yes, it is possible. if the test system is missing some headers and libraries to run certain tests, by default, it should not fail on you, and ./configure could provide you a summary at the end to tell you some tests would not compile and run. Cai Qian > 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
