Re: GSoC project idea: non-recursive automake project
Hi Harlan, * Harlan Stenn wrote on Sat, Mar 19, 2011 at 01:26:58AM CET: > If there was a student interested in showing how "easy" it was to use > automake to do non-recursive Makefiles for a project, I'd be willing to > co-mentor and work with them to convert NTP to that sort of operation. Thanks for the co-mentoring offer and the SoC idea! I have a question though: how much work do you expect this to be? Haven't looked at NTP in a long time, but typically, turning a project into non-recursive was either a straightforward to trivial task of maybe 1-2 days for somebody experienced with autotools, or something difficult to impossible due to limitations in either of Make, Automake, or third-party bits. Maybe such a proposal could be enhanced to avoid having not enough work: For example, while converting NTP, the student could start a document with a general recipe for this conversion. And then maybe try it out on a couple more projects, and possibly refine the recipe along the way. For students that get very far, they could also try working on limitations in other tools should they come across them. This way the student will not get bored. However, it might be harder to define specific goals to achieve, or to define success in the end. Would you be willing to formulate this as a proposal for the GNU proposals wiki page? I should note that I certainly don't have unlimited mentoring time. I expect to be able to mentor one student, and I'm sure co- or backup- mentoring beside that should be possible, but if we can find another person to help that would only be good. Cheers, Ralf
Re: GSoC project idea: non-recursive automake project
On Sat, Mar 19, 2011 at 10:38:39AM +0100, Pippijn van Steenhoven wrote: > On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: > > If there was a student interested in showing how "easy" it was to use > > automake to do non-recursive Makefiles for a project, I'd be willing to > > co-mentor and work with them to convert NTP to that sort of operation. > > It's mostly trivial. How hard are GSoC projects supposed to be? Being a student, I'd be willing to prove it ;) -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: GSoC project idea: non-recursive automake project
On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: > If there was a student interested in showing how "easy" it was to use > automake to do non-recursive Makefiles for a project, I'd be willing to > co-mentor and work with them to convert NTP to that sort of operation. It's mostly trivial. How hard are GSoC projects supposed to be? -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: GSoC project idea: non-recursive automake project
On Sat, Mar 19, 2011 at 10:38:39AM +0100, Pippijn van Steenhoven wrote: > On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: > > If there was a student interested in showing how "easy" it was to use > > automake to do non-recursive Makefiles for a project, I'd be willing to > > co-mentor and work with them to convert NTP to that sort of operation. > > It's mostly trivial. How hard are GSoC projects supposed to be? Ok, having taken a glance at the NTP Makefiles, I have to correct that. It's trivial to do it, but a little less so to do it right, making sure it works just like before. I'm still willing to do the project. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: [GSoC Proposal] automake - Interfacing with a test protocol like TAP or subunit
On Saturday 19 March 2011, Harlan Stenn wrote: > I'm curious/interested about the TAP effort, as it might tie in nicely > with some stuff we're working on for NTP: > > https://support.ntp.org/bin/view/Dev/GSoCProjectIdeas#Unit_tests > Nice! Having a real use case from the very beginning would be great, and would surely benefit the desing and implementation in Automake. Regards, Stefano
Re: GSoC project idea: non-recursive automake project
Hi Ralf, Ralf wrote: > * Harlan Stenn wrote on Sat, Mar 19, 2011 at 01:26:58AM CET: > > If there was a student interested in showing how "easy" it was to use > > automake to do non-recursive Makefiles for a project, I'd be willing to > > co-mentor and work with them to convert NTP to that sort of operation. > > Thanks for the co-mentoring offer and the SoC idea! > > I have a question though: how much work do you expect this to be? > Haven't looked at NTP in a long time, but typically, turning a project > into non-recursive was either a straightforward to trivial task of > maybe 1-2 days for somebody experienced with autotools, or something > difficult to impossible due to limitations in either of Make, Automake, > or third-party bits. If my goal was only to get a basic non-recursive Makefile setup going for NTP, then yeah, I think it might be fairly easy. Larry McVoy once said something like "In theory, theory and practice are the same. But in practice, they are not." There are various "use" cases that should be explored - running make from the top-level, running make from a subdir where a specific target is asked to be built, etc. The description, choices, and options should all be documented. > Maybe such a proposal could be enhanced to avoid having not enough work: > For example, while converting NTP, the student could start a document > with a general recipe for this conversion. And then maybe try it out on > a couple more projects, and possibly refine the recipe along the way. > For students that get very far, they could also try working on > limitations in other tools should they come across them. > > This way the student will not get bored. However, it might be harder > to define specific goals to achieve, or to define success in the end. Yes, and I'd look at "making it 'go' on NTP" be part of the proof-of-concept that we had a reasonably robust design with adequate documentation. > Would you be willing to formulate this as a proposal for the GNU > proposals wiki page? I think so, yes. My "problem" is that I will only have a few hours' time to work on this between now and this Monday, and I will probably have no time from this Tuesday until the following Monday. > I should note that I certainly don't have unlimited mentoring time. > I expect to be able to mentor one student, and I'm sure co- or backup- > mentoring beside that should be possible, but if we can find another > person to help that would only be good. Yup, I suspect I'll be at my "maximum load" for GSoC this year, too. H
Re: GSoC project idea: non-recursive automake project
Pippijn wrote: > On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: > > If there was a student interested in showing how "easy" it was to use > > automake to do non-recursive Makefiles for a project, I'd be willing to > > co-mentor and work with them to convert NTP to that sort of operation. > > It's mostly trivial. How hard are GSoC projects supposed to be? I'll assume you have seen my reply to Ralf. >From my POV, I have heard folks saying for a long time how "easy" it is to use automake to produce non-recursive Makefiles. But I haven't seen this in practice, and on the (few) attempts I have made to figure it out myself and look for examples, I have not yet been able to find a really useful solution. What I think we'd want is a reasonably well-documented description of how to use automake to produce a source tree where one can: - run "make" from the top-level of the tree and all of the normal things happen (and all of the normal targets work) - run "make" from a subdir, which would handle all of the normal targets for that subdir, and would also automatically handle *all* of the dependencies needed for the specified targets in that subdir (like prerequisite libraries). H
Re: GSoC project idea: non-recursive automake project
Pippijn wrote: > On Sat, Mar 19, 2011 at 10:38:39AM +0100, Pippijn van Steenhoven wrote: > > On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: > > > If there was a student interested in showing how "easy" it was to use > > > automake to do non-recursive Makefiles for a project, I'd be willing to > > > co-mentor and work with them to convert NTP to that sort of operation. > > > > It's mostly trivial. How hard are GSoC projects supposed to be? > > Being a student, I'd be willing to prove it ;) I'm happy to participate on this one, too. H
Re: [GSoC Proposal] automake - Interfacing with a test protocol like TAP or subunit
On Sat, Mar 19, 2011 at 1:03 PM, Stefano Lattarini wrote: > ABSTRACT: > > The Test Anything Protocol (TAP) is a simple text-based protocol > that allows communication between test scripts and a test harness. ... > Now, in all honesty, I must say that I've chosen TAP not only for its > objective qualities and merits, but also because I have some previous > knowledge of it (which allowed me to present a more concrete proposal > and a meaningful roadmap) and I personally like it (which will probably > be a powerful motivator to overcome the unavoidable hurdles I'll > encounter down the road). > > Still, there might be very valid competing alternatives to TAP out there, > which I might not know about, but that in the long run would offer > Automake more advantages and interoperabilty, thus outweighting the two > "personal" advantages of TAP I've reported above. So, if anyone who's > reading this has proposals about viable alternatives to TAP, please > speak up -- your contribution is appreciated! TAP is an extremely simple protocol, and the extensions to it to support things like not needing to maintain the count of tests, additional debug data and so on are pretty rudimentary. subunit, which I've mentioned before was written after TAP, to solve similar problems and address the issues in TAP itself. While the users of a protocol aren't really an indicator of the protocols worth, projects as large as samba are using subunit. Unlike TAP subunit supports attachments (binary and text) to tests, test naming, tagging, timestamping (permitting robust timing data even in parallelised or distributed testing). Integrating with TAP is basically uninteresting to anyone working in a high level language: Python, Ruby,Java, C++ etc. -Rob
