Re: GSoC project idea: non-recursive automake project
Harlan Stenn writes: > Larry McVoy once said something like "In theory, theory and practice are > the same. But in practice, they are not." Maybe he did say that at some point, but it's a hoary old quote (attributed to Yogi Berra, among others), and certainly didn't originate with Larry... -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche
Re: GSoC project idea: non-recursive automake project
On Mon, Mar 21, 2011 at 3:09 PM, Nick Bowler wrote: > * Modify gnulib so that it can be easily integrated into a > non-recursive automake setup. One could look to libltdl for > inspiration here. How about modifying GCC. That should take some time, I think :) :) :)
Re: GSoC project idea: non-recursive automake project
On 2011-03-22 07:36 -0700, Ben Pfaff wrote: > Nick Bowler writes: > > > * Modify gnulib so that it can be easily integrated into a > > non-recursive automake setup. One could look to libltdl for > > inspiration here. > > It doesn't have to be modified. An Automake setup can easily and > usefully contain a mix of recursive and non-recursive subdirectories. Sorry, I meant integrated in a manner such that the gnulib bits are built non-recursively. While you can of course use a recursive make to build gnulib, you still tend to be left with the usual problems that plague recursive builds: specifically that dependencies between the subtrees using separate makefiles tend to be incomplete, resulting in reduced concurrency and/or incorrect builds. A recursively-built gnulib is no exception here. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Re: GSoC project idea: non-recursive automake project
Nick Bowler writes: > * Modify gnulib so that it can be easily integrated into a > non-recursive automake setup. One could look to libltdl for > inspiration here. It doesn't have to be modified. An Automake setup can easily and usefully contain a mix of recursive and non-recursive subdirectories. -- Ben Pfaff http://benpfaff.org
Re: GSoC project idea: non-recursive automake project
On Mon, Mar 21, 2011 at 7:36 PM, Roger Leigh wrote: > Can't automake rewrite the relative paths to be absolute? This would break things, for example when using WINE via wrapper scripts, require fixed srcdir pathes... oki, Steffen
Re: GSoC project idea: non-recursive automake project
On 2011-03-19 12:07 +0100, Ralf Wildenhues wrote: > Maybe such a proposal could be enhanced to avoid having not enough work: [...] > 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. I have two suggestions which could be part of a GSoC project about non-recursive automake. I have no idea what the scope of these are. * Modify automake so that package authors can specify source files more easily in a non-recursive setup. Currently, the full path from the top of the source tree must be specified for every source file. Some ideas for how to go about this can be found in the mailing list archives. A successful solution here should allow a project with a well-written, non-recursive Makefile.am to rearrange their directory structure while only requiring relatively minor changes to Makefile.am. * Modify gnulib so that it can be easily integrated into a non-recursive automake setup. One could look to libltdl for inspiration here. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Re: GSoC project idea: non-recursive automake project
On Mon, Mar 21, 2011 at 11:49:39AM -0400, NightStrike wrote: > On Sat, Mar 19, 2011 at 3:45 PM, Harlan Stenn wrote: > > 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. > > A solution to *what* exactly? Said another way, what *exactly* is the > problem with automake+non-recursion that you would want solved? > > I personally have found that the only obstacle to me is minor -- all > sources have to be specified relative to the top level directory, even > in a subdir Makefile fragment that gets included in the top. Surely even this is a solvable problem. Can't automake rewrite the relative paths to be absolute? Obviously this wouldn't necessarily work for some complex custom rules, but in the general case it would be a big bonus. It would also mean that any variables such as foo_SOURCES in a subdirectory could have the absolute path prefixed to all the files on inclusion, which would mean I could convert to using a single top-level Makefile and keep all the separate Makefile.ams in the subdirectories, where it makes sense to have them alongside the code they build. I certainly wouldn't be averse to rewriting any custom rules to gain this. I've wanted something like this for years, in fact. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: GSoC project idea: non-recursive automake project
On Sat, Mar 19, 2011 at 3:45 PM, Harlan Stenn wrote: > 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. A solution to *what* exactly? Said another way, what *exactly* is the problem with automake+non-recursion that you would want solved? I personally have found that the only obstacle to me is minor -- all sources have to be specified relative to the top level directory, even in a subdir Makefile fragment that gets included in the top. > 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).
Re: GSoC project idea: non-recursive automake project
On 03/19/2011 01:45 PM, Harlan Stenn wrote: > 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). I'd be *very* interested to see how this second item is done. One of the inherent benefits of recursive make is that there's a self-contained Makefile in each directory. Thus, you can run make from that directory. I'm wondering how you do that with only one top-level Makefile. --john
Re: GSoC project idea: non-recursive automake project
Hello Pippijn, * Pippijn van Steenhoven wrote on Sat, Mar 19, 2011 at 10:47:35AM CET: > 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 ;) If you would like to apply as student for this GSoC project, can you please formulate a project proposal (as is needed for a GSoC application anyway) and post it here? Please take into account what else was said in this thread about having enough work for a SoC term. (We can help with more ideas about how one could extend Automake if that's unclear.) Harlan's description of the task will soon appear in the archives of http://lists.gnu.org/archive/html/summer-of-code/2011-03/threads.html and eventually also on http://www.gnu.org/software/soc-projects/ideas-2011.html but it is still fairly vague. Then, I remember reading you on this list before, but not yet much in a development role. I have no idea whether you know the autotools code or NTP well. Now, I don't want to put you on the spot, and prior development experience is not a requirement for GSoC applications, but if your proposal is going to encompass hacking on NTP and/or Autotools, it would help to see or be able to judge your coding and working together skills in some way or other. You could help us with something like looking at the debbugs for Automake and working on some bug (or even just outlining strategies to do so); or addressing an issue that somebody reported on the mailing list; or enhancing the documentation in some way; or similar for NTP. There's no need for you to find out everything (or even much) yourself. In fact, if you ask questions on the way, that will probably make things easier for us. If you don't see something feasible to do, we can probably also come up with a small (maybe 1-2 hr) task. Finally, I should add that I'm off-list for the second half of this week (starting Wednesday; but I should be back sometime next weekend) and otherwise usually read mails twice a day, so expect some latency. Thanks, Ralf
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 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
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
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 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? 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
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