RE: Autmoake (test) editing
-Original Message- From: Bob Friesenhahn [mailto:bfrie...@simple.dallas.tx.us] Sent: Tuesday, March 31, 2015 4:05 PM To: Arthur Schwarz Cc: automake@gnu.org Subject: RE: Autmoake (test) editing On Tue, 31 Mar 2015, Arthur Schwarz wrote: > Editorial comments on TAP I successfully used the TAP documentation to add TAP test support to my own project. Did you intend to not include a patch to fix the issues you noticed? I think that ".trs" files must be a project-specific test script extension. All the TAP script needs to do is to print the expected number of 'ok' and 'not ok' messages. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ --- Well, I've never done a patch. More appropriately, the Automake document needs a thorough review and rewriting. I don't have the knowledge to do that, I don't know automake. More appropriately, the patches would be more extensive then just casual corrections, and I don't have the authority to do them. My argument is that the document unsuccessfully presents a quality product. I can participate in a dialog of how to change the product documentation so that it provides the Autoake developers intent in a manner suitable for a new user, and suitable as a reference for an experienced user. But, sign, I haven't been asked. If you can provide some guidance as to what needs to be done in an .am file to install and use TAP, I'd appreciate it. Oh, one last thing. It is my feeling that the intent of a product document is to state everything that a user needs to know to use the product, not to prod the user to 'guess or infer' how something works, and then to experiment until the right guess leads to the right result. Thanks for writing; art
RE: Autmoake (test) editing
On Tue, 31 Mar 2015, Arthur Schwarz wrote: Editorial comments on TAP I successfully used the TAP documentation to add TAP test support to my own project. Did you intend to not include a patch to fix the issues you noticed? I think that ".trs" files must be a project-specific test script extension. All the TAP script needs to do is to print the expected number of 'ok' and 'not ok' messages. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
RE: Autmoake (test) editing
Editorial comments on TAP 15.4.1 Introduction to TAP, pg. 112 pg. 112 "... among different test harnesses ..." Automake has defined only one test harness, the Parallel Test Harness. Since this is an Automake document mentioning of others makes no sense. The sentence should be deleted or changed. pg. 112 "... will present the results on the console in the usual fashion ..." What is probably meant is that the TAP output will be presented. the sentence otherwise doesn't make sense. pg. 112 "(see [Testsuite progress on console], page 103)" There is no Testuite progress on console, and the hyperlink is to the Parallel Test Harness. The Custom Driver, which is not a test harness, has a Section 15.3.3.3 Testsuite progress output on pg. 111 and this is exclusive to the custom driver. Perhaps the "usual fashion" needs some description. pg. 112 "(see [Basics of test metadata], page 105" There is no section titled "Basics of test metadata" and the hyperlink is to the Parallel Test Harness, 15.2.3 Parallel Test Harness pg. 105. There are various mentions to the .trs file and the contents of the .trs file. References to the .trs file are on pgs. 105, 106, 107, 108, 110. A description of the contents of a .trs file is given in 15.3.3.2 Log files generation and test results recording, pg. 110 but this description is defined for the custom driver and, one would presume, is exclusive to the custom driver. There is no definition of the contents of a .trs file defined for use by TAP (or anything other than the custom driver). What was the intent of this sentence? pg. 112 "Apart from that, it will try to remain as much compatible as possible with pre-existing and widespread utilities, such as the prove utility, at least for the simpler usages." This is a description of the Automake generated test (something) and its use by the user. If other products are involved then the intent of their involvement should be defined and the expected input to these product specified. My guess is that the sentence means that the .trs file data is available to products external to the Automake generated test facilities for analysis. I think that you probably mean to include the .log files also. And that this data can be configured by the test case/test suite execution and analysis software to conform to the data input requirement for these tools. I have not idea what this has to do with Automake. pg. 112 "... various independent implementations in different languages ..." Which implementations are supported by Automake? pg. 112 "'Test::Harness::TAP'" This hyperlink no longer works. http://testanything.org/tap-specification.html would probably work better. pg. 112 "... The most relevant real-world usages of TAP are obviously in the testsuites of perl ..." This says that unless Automakee is generates code to test a perl development, that TAP is not relevant. Is this really the intent? To describe a facility which is not "most relevant" other than the restricted environment of perl development? 15.4.2 Use TAP with the Automake test harness, pg. 112 The only, and I mean only, test harness so far defined is the Parallel Test Harness. Do you mean that TAP execution is concurrent? pg. 112 "... support for third-party test drivers ..." Is there a reference to integrating third-party test drivers? There is a table of contents entry for third party Makefiles. The index has a reference to integration with third-part packages, which seems to lead to third-party Makefiles, and the text has references to various third-party things, but I really don't see anything dealing with integrating third party test drivers, unless you, perhaps, mean custom test drivers? pg. 112 "Apart from the options common to all the Automake test drivers ..." The reference, 15.3.3.1 Command-line arguments for test drivers, pg. 110, is to command-line interfaces to custom drivers. Are all Automake drivers custom drivers? Makes sense but custom drivers aren't Automake drivers. They are developer constructed drivers which Automake provides an integrated interface for. there still is no definition of what a 'driver' is. Can it be a script or a C/C++ program? pg. 112 "... tap-driver.sh supports the following options ..." No mechanism has been presented to tell how the user/developer inputs options (however there is an example below, with no explanation). If it is the developer, is it through autoconf/reconf options (clearly not allowed)? if it is the user is it through 'make' options? And, there is no distinction drawn here between the developer (an automake user) and the user (a Automake generated make file user). pg. 113 "Here is an example ..." You are using an example, with no description, to define how to integrate TAP into Autom
Re: how should package config files be installed
# ebl...@redhat.com / 2015-03-31 14:30:39 -0600: > On 03/31/2015 02:26 PM, Roman Neuhauser wrote: > > # ebl...@redhat.com / 2015-03-31 11:40:52 -0600: > >> On 03/31/2015 11:25 AM, Andy Falanga (afalanga) wrote: > >>> I want to distribute the correct *.pc files with the libraries I'm > >>> building. While it's a simple matter to find the format of this > >>> file (by examining existing ones or online), I'd like to know if > >>> there's a preferred procedure for generating these files. What > >>> should be done in order to make this work? > >> > >> .pc files are created by the pkg-config tool. More details on their web > >> site: http://www.freedesktop.org/wiki/Software/pkg-config/ > > > > i can't find any support for this claim anywhere in that "web site" > > (it's a short page). can you be more specific? > > [...] the page I linked to above includes a link to their FAQ: > > http://people.freedesktop.org/~dbn/pkg-config-guide.html#faq > > which goes into more details. sorry but no, it does not go into more detail. the most i can find on the topic of generating .pc files is in pkg-config(1): You would normally generate the file using configure, so that the prefix, etc. are set to the proper values. The GNU Autoconf manual recommends generating files like .pc files at build time rather than configure time, so when you build the .pc file is a matter of taste and preference. which kinda points back our way. > It's a different project that automake, so you'll probably get better > support on the pkg-config mailing list than you will here. > I have not personally converted a project over to using pkg-config, so > I can't provide any better details than "read the manual". that'd be a better answer to the original question, i guess. -- roman
RE: how should package config files be installed
> -Original Message- > From: Bob Friesenhahn [mailto:bfrie...@simple.dallas.tx.us] > Sent: Tuesday, March 31, 2015 2:47 PM > To: Andy Falanga (afalanga) > Cc: automake@gnu.org > Subject: Re: how should package config files be installed > > On Tue, 31 Mar 2015, Andy Falanga (afalanga) wrote: > > > I want to distribute the correct *.pc files with the libraries I'm > > building. While it's a simple matter to find the format of this file > > (by examining existing ones or online), I'd like to know if there's a > > preferred procedure for generating these files. What should be done > > in order to make this work? > > I am not sure what the correct procedure is, but I packages I maintain > (and many others) use autoconf to configure a templated "foo.pc.in" > and then install it using Automake. Hm ... now that sounds like a nice, workable, solution. Andy
Re: how should package config files be installed
On Tue, 31 Mar 2015, Andy Falanga (afalanga) wrote: I want to distribute the correct *.pc files with the libraries I'm building. While it's a simple matter to find the format of this file (by examining existing ones or online), I'd like to know if there's a preferred procedure for generating these files. What should be done in order to make this work? I am not sure what the correct procedure is, but I packages I maintain (and many others) use autoconf to configure a templated "foo.pc.in" and then install it using Automake. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: how should package config files be installed
On 03/31/2015 02:26 PM, Roman Neuhauser wrote: > # ebl...@redhat.com / 2015-03-31 11:40:52 -0600: >> On 03/31/2015 11:25 AM, Andy Falanga (afalanga) wrote: >>> I want to distribute the correct *.pc files with the libraries I'm >>> building. While it's a simple matter to find the format of this >>> file (by examining existing ones or online), I'd like to know if >>> there's a preferred procedure for generating these files. What >>> should be done in order to make this work? >> >> .pc files are created by the pkg-config tool. More details on their web >> site: http://www.freedesktop.org/wiki/Software/pkg-config/ > > i can't find any support for this claim anywhere in that "web site" > (it's a short page). can you be more specific? It's a different project that automake, so you'll probably get better support on the pkg-config mailing list than you will here. But the page I linked to above includes a link to their FAQ: http://people.freedesktop.org/~dbn/pkg-config-guide.html#faq which goes into more details. I have not personally converted a project over to using pkg-config, so I can't provide any better details than "read the manual". -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: how should package config files be installed
# ebl...@redhat.com / 2015-03-31 11:40:52 -0600: > On 03/31/2015 11:25 AM, Andy Falanga (afalanga) wrote: > > I want to distribute the correct *.pc files with the libraries I'm > > building. While it's a simple matter to find the format of this > > file (by examining existing ones or online), I'd like to know if > > there's a preferred procedure for generating these files. What > > should be done in order to make this work? > > .pc files are created by the pkg-config tool. More details on their web > site: http://www.freedesktop.org/wiki/Software/pkg-config/ i can't find any support for this claim anywhere in that "web site" (it's a short page). can you be more specific? -- roman
Re: how should package config files be installed
On 03/31/2015 11:25 AM, Andy Falanga (afalanga) wrote: > I want to distribute the correct *.pc files with the libraries I'm building. > While it's a simple matter to find the format of this file (by examining > existing ones or online), I'd like to know if there's a preferred procedure > for generating these files. What should be done in order to make this work? .pc files are created by the pkg-config tool. More details on their web site: http://www.freedesktop.org/wiki/Software/pkg-config/ -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
how should package config files be installed
I want to distribute the correct *.pc files with the libraries I'm building. While it's a simple matter to find the format of this file (by examining existing ones or online), I'd like to know if there's a preferred procedure for generating these files. What should be done in order to make this work? Thanks, Andy
