Re: Do convenience libraries propagate -R linker flags?

[Ralf Wildenhues]

Hello Rhys,

* Rhys Ulerich wrote on Mon, Mar 14, 2011 at 05:34:04PM CET:
> I've got a convenience library where the LDFLAGS includes -R:
> noinst_LTLIBRARIES = libsomething.la
> ...
> libsomething_la_LDFLAGS = -Rsomewhere
> and I indeed see "-Rsomewhere" appear within libsomething.la's dependency_libs
> line the way I expect.
> 
> In another directory, I build a program depending on libsomething.la
> bin_PROGRAMS = myprog
> myprog_LDADD = ../lib/libsomething.la
> and then issue 'make install' to install it.
> 
> After installation, I'm not seeing '-Rsomething' appear within the installed
> binary's rpath according to 'readelf -d myprog'. 'ldd myprog' issued after
> emptying my LD_LIBRARY_PATH confirms that -Rsomething isn't present.
> 
> Should I expect -R flags provided at convenience library creation time to be
> propagated to an installed binary which uses that convenience library?  If
> not, I'll stop trying.  If so, I'll see if I can get a recreate for what
> I'm observing.

I think they are not propagated currently for convenience archives.  As
to whether they should, I'm not sure.  I remember that this has been
reported before.  I also remember that the issue has not been entirely
noncontroversial.

Somebody would have to dig in mailing list and commit history (of the
Libtool project) to find out for sure.

Cheers,
Ralf

My drafts for Google Summer of Code applications

[Stefano Lattarini]

Hello automakers.

Good news: GNU has been accepted as a mentoring organization for this
year's GSoC (Google Summer of Code), and the GNU "Project Suggestion"
page at:
  
lists a couple of Automake-related projects for which an application
could be submitted.

Now, barring last-minute problems, I should be elegible to
partecipate as a student to GSoC, so I'd like to submit applications
for those two projects.

So, here I'm going to post my first drafts for those applications, with
the hope of getting criticism, suggestions, and general feedback.  This
would help my proposals (and thus the new features that will result
from them, in case they are accepted) to be more informed about, and
moulded by, the opinions, needs and experiences of a real user base.

I'll post each proposal in its own follow-up message, in order to
keep the thread nicely strucured.

Thanks,
  Stefano

[GSoC Proposal] automake - Exploit more features of GNU make in Automake

[Stefano Lattarini]

ABSTRACT:
  The primary target of this project is to enable Automake-generated
  Makefiles to exploit more features of GNU make.  The exact details
  of how and on what level this is to be implemented (e.g., at Automake
  time by the developer, at configure time by the user, or a mixture of
  both) is to be determined in the design phase of the project.

DETAILS:
  See attachements.

-*-*-

In all honesty, I'm not completely sure the deliverables promised in this
proposal are truly enough to warrant a GSoC assignation; but at the moment
I cannot think how to extend them without risking to make the proposal too
big, thus ending up with an incomplete (or worse malfunctioning) result.

Do you think the deliverables are enough?  If not, do you have suggestions
about how they could be extended/improved?

Also, if there are GNU make specific improvements you'd like to see in
Automake-generated Makefiles, but which are not listed in my proposal,
feel free to speak up.  Feedback is appreciated.

Thanks,
  Stefano
Student Identification
==

 Name: Stefano Lattarini
 Email address: stefano.lattar...@gmail.com


The name of the project
===

 automake - Exploit more features of GNU make in Automake


Abstract


 The primary target of this project is to enable Automake-generated
 Makefiles to exploit more features of GNU make.  The exact details
 of how and on what level this is to be implemented (e.g., at Automake
 time by the developer, at configure time by the user, or a mixture
 of both) is to be determined in the design phase of the project.


Portability of Automake-generated Makefiles
===

 One of the main goals of Automake is to produce Makefiles that are
 highly portable.  In fact, Automake-generated Makefiles are expected
 to work "out-of-the-box" not only with with GNU and BSD make (recent
 and older versions alike), but also with most vendor implementations
 of make (Solaris, AIX, HP-UX, IRIX, ...).

 This portability is much appreciated by many developers who use
 Automake; see for example these pots of a recent discussion on the
 automake mailing list:
   
   

 Automake is quite successful in this regard, managing to implement
 successfully and in portable fashion some advanced, and even tricky,
 features; among them, automatic dependency tracking, an advanced and
 highly parallelizable testsuite harness  (the "parallel-tests" option)
 and the ability to dynamically render make's output less verbose and
 more informative (the "silent-rules" option).

 Moreover, Automake goes to great length to work around known bugs and
 limitations of different make implementations, and to accommodate for
 incompatibilities between them (one example for all: the dreaded
 VPATH issues).

 But all this portability comes at a price ...


When portability brings disadvantages
=

 The Makefiles generated by Automake are definitely suboptimal w.r.t.
 GNU make, which have much more advanced capabilities than those such
 Makefiles expect and use.  The Automake-generated Makefiles are thus
 slower, larger, and more difficult to understand then they would be
 by taking advantage of more GNU make features.

 And while, for example, Autoconf-generated configure scripts can
 dynamically search for a better shell and/or probe the shell features
 *at runtime* to try to activate optimized implementations of the
 offered primitives, a similar approach is nigh to impossible for the
 Automake-generated Makefiles, due to very limited nature of the
 make language (both as specified by POSIX, and as implemented by many
 make programs Automake strives to support).


Benefits of this proposal
=

 - Various optimizations in speed, size and clarity of the generated
   Makefiles, when GNU make is used or can be assumed.

 - Such optimizations would be particularly useful since they would
   benefit 80-90% of the user base.  In fact, GNU/Linux installations
   (for which GNU make is the system make) represent a high percentage
   of UNIX installations; moreover, GNU/make is also the default make
   program for the two more widespread UNIX-like environments for
   Microsoft Windows (Cygwin and MSYS/MinGW); finally, lots of BSD
   and Solaris users have GNU make installed in addition to their
   native make (FreeBSD offers a port and a package for it, and Sun
   ships it as third-party officially supported software).

 - Probably make the use of Automake more widespread and enticing.  In
   fact, in the present state of facts, some projects are scared away
   because the Automake Makefiles are ugly, complicated, and, worse of
   all, quite suboptimal when run with GNU make, which might very well
   be the only make implementation those projects want to support or
   can affo

[GSoC Proposal] automake - Interfacing with a test protocol like TAP or subunit

[Stefano Lattarini]

ABSTRACT:

  The Test Anything Protocol (TAP) is a simple text-based protocol
  that allows communication between test scripts and a test harness.

  The primary target of this project is the implementation of a TAP-consumer
  testsuite harness in Automake-generated Makefiles.  This way, a software
  package using Automake and having a scripts-based testsuite would be able
  to run multiple checks in each test script, and communicate the result of
  each of those checks separately to the test harness, which could then
  issue more faithful statistics about the number of failed/passed/skipped
  checks.

  A secondary objective is to enhance Autotest-generated test scripts to
  allow them to become TAP producers.

DETAILS:

  See attachements.

-*-*-

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 hasproposals about viable alternatives to TAP, please
speak up -- your contribution is appreciated!

Thanks,
  Stefano
Student Identification
==

 Name: Stefano Lattarini
 Email address: stefano.lattar...@gmail.com


The name of the project
===

 automake - Interfacing with a test protocol like TAP or subunit


Abstract


 The Test Anything Protocol (TAP) is a simple text-based protocol
 that allows communication between test scripts and a test harness.

 The primary target of this project is the implementation of a TAP-consumer
 testsuite harness in Automake-generated Makefiles.  This way, a software
 package using Automake and having a scripts-based testsuite would be able
 to run multiple checks in each test script, and communicate the result of
 each of those checks separately to the test harness, which could then
 issue more faithful statistics about the number of failed/passed/skipped
 checks.

 A secondary objective is to enhance Autotest-generated test scripts to
 allow them to become TAP producers.


The parallel-tests driver and its limits


 In the recent years, Automake's built-in support for the generation
 of testsuite harnesses has become quite sophisticated.  In particular,
 the "parallel-tests" driver has performed very good.

 That driver is targeted at testsuites comprised of test scripts which
 are mostly independent one from the other, and safe to run in parallel.
 It is implemented in portable make (obviously with the contribution of
 portable POSIX utilities, such as the shell, awk, sed, etc.), but still
 manages to offer many useful and pretty advanced features (please refer
 to the Automake documentation for more details).

 Still, the parallel driver still has one major limit.

 In a scripts-based testsuite, it's common for a single test script
 to run checks for multiple (usually related) features, and/or against
 multiple bugs at once -- especially in case these checks require a
 similar (or even identical) setup.  And while it would usually be
 feasible to separate such related checks into different test scripts,
 that might require a too-high overhead, either in test execution time
 or in programmer coding time.

 The problem with the current Automake parallel-tests driver (and also
 with its precursor, the "simple-tests" driver) is that the results of
 all the checks run by an individual test script are hopelessly condensed
 into the single final exit status of the script.  So there is no way
 to distinguish between, say, a test script that failed because one check
 out of N in it failed, from one which failed because all the N checks
 in it failed.


Possible enhancements with the TAP protocol


 The Test Anything Protocol (TAP) is a simple protocol that allows
 communication between test scripts and a test harness.  It allows
 individual tests (TAP producers) to communicate test results to the
 testing harness (TAP consumer) in a language-agnostic way.  What is
 important for us is that, using TAP, a single test script can safely
 run multiple checks and report the outcome of each of them separately
 to the harness; the results will then be properly displayed and
 accounted for by the harness, with the right level of granularity.

 So, for example, if we have a TAP-aware test script that fails because
 one check out of 20 in it failed, the test harness won't count that as
 "1 failure, 0 passes", but as a "1 failure, 19 passes".

 Thus, A

Re: [GSoC Proposal] automake - Interfacing with a test protocol like TAP or subunit

[Harlan Stenn]

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

GSoC project idea: non-recursive automake project

[Harlan Stenn]

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.

-- 
Harlan Stenn 
http://ntpforum.isc.org  - be a member!