bug#7988: the manual suggests installing macro files to hard-coded location
Hello Stefano,
On 3/19/11 8:36 AM, Stefano Lattarini wrote:
On Saturday 05 February 2011, Peter Johansson wrote:
I find the last sentence a bit strange because to me that sounds like
Automake suggests that packagers should install macro files in a
hard-coded directory not relative to $(prefix).
Yes, this is exactly what it suggests. Unfortunately, this is currently
the best way to allow aclocal to find the installed third-pary macro file;
for more information see:
http://www.gnu.org/software/automake/manual/html_node/Macro-Search-Path.html
With the same logic, the best way to intall header files would be to ask
gcc about its search path and intall header files where gcc will find
them - typically in `/usr/local/include'.
I think this would be suboptimal and a better way to do it is to install
headers in `$(includedir)' and have this set to `${prefix}/include' as
default but also give the installer the freedom to change this location
if desired at configure time or even at make time.
IMVHO, that approach works also for m4 files. Install m4 files in
`$(aclocaldir)', whose default value is `${datadir}/aclocal'. If that
happens to be a place aclocal never heard of, the user can always supply
'-I' flags as needed.
On one system at work I have aclocal installed in `/usr/bin/' and since
I'm not root I can not install stuff into `/usr' and would find it
annoying if packages insisted on installing m4 files into
`/usr/share/aclocal' although I configure with `--prefix=$HOME'. And on
top of that distcheck typically fails if one tries to install things to
a location outside the $(prefix) tree.
Another viable approach would be to install the third-party macro file
in `$(third-party-prefix)/share/aclocal', and then extend the file
`$(aclocal-prefix)/share/aclocal/dirlist' to list that directory too; but
this would mean *modify* a possibly pre-existing file (and in a hard-coded
location too), and I'm not sure this is a wise move (but maybe might be
worth citing in the documentation anyway... Opinions?)
IMVHO that doesn't sound like an improvement. Say that I, e.g., install
an old version of GSL with --prefix=/usr/local/gsl-1.6. That doesn't
mean I want aclocal to look for m4 files in
`/usr/local/gsl-1.6/share/aclocal'. And what happens with all the times
I install my own package within distcheck, would that prefix
(`pwd`/_inst) also be added in `dirlist'?
Finally, note that this problem should be ameliorated once the pending
patches introducing support for the ACLOCAL_PATH environment variable
are merged:
http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00089.html
At that point, a thid-party package providing macro files can install them
into `$(third-party-prefix)/share/aclocal', and then tell the user to
extend the system-wide definition of ACLOCAL_PATH accordingly (somewhat
similarly to what libtool install rules does with `LD_LIBRARY_PATH').
Sounds good.
Thanks,
Peter
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 stefano.lattar...@gmail.com 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
