mainGnuTLS - Support: sr #108615, Regenerating documentation fails...

 
 

sr #108615: Regenerating documentation fails when sed is BSD sed

Submitter:  Ryan Carsten Schmidt <ryandesign>
Submitted:  Mon 14 Jul 2014 06:40:45 AM UTC
   
 
Category:  Core library Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  nmav
Open/Closed:  Closed Operating System:  Mac OS
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 27 Jul 2014 01:23:48 PM UTC, comment #5: 

Doing some testing, I see that's not going to work. GNU sed requires no space between -i and the argument, while BSD sed requires a space if it's the empty string. A portable solution that does work with both seds is to just specify a backup suffix, e.g. "-i.bak" works.

Ryan Carsten Schmidt <ryandesign>
Sun 27 Jul 2014 01:20:51 PM UTC, comment #4: 

The argument to the -i flag is the suffix to use on the backup file. In GNU sed the argument is optional, and if not specified, no backup is made. In BSD sed the argument is mandatory, and if you don't want a backup, specify the empty string.

Ryan Carsten Schmidt <ryandesign>
Sun 27 Jul 2014 12:39:23 PM UTC, comment #3: 

All uses of -i have filenames as argument. Do you mean rearranging the arguments so that the filenames come after -i? Would that address that issue?

Nikos Mavrogiannopoulos <nmav>
Group administrator
Sun 27 Jul 2014 12:34:18 PM UTC, comment #2: 

Right, using $(SED) will ensure the sed that configure found gets used, but that won't fix the build failure if configure found a BSD sed.

Disabling documentation building is one idea, but is it really that hard to support BSD sed as well? For example, as I mentioned, always supply an argument to the -i flag: -i '' would be the portable equivalent to the GNU-specific -i you're currently using.

Ryan Carsten Schmidt <ryandesign>
Sun 27 Jul 2014 12:27:57 PM UTC, comment #1: 

Hello,
 I've done the replacement of sed with $(SED) in makefile.am, but I'm not sure whether that this change would be sufficient to build documentation in any system without the gnu tools. Would it make sense to use "--disable-doc" and ship only the included documentation?

Nikos Mavrogiannopoulos <nmav>
Group administrator
Mon 14 Jul 2014 06:40:45 AM UTC, original submission:  

I found that gnutls 3.3.5 fails to build on OS X, and presumably other BSD-derived systems like FreeBSD and OpenBSD whose "sed" program is BSD sed instead of GNU sed, if I make a change to the sources that causes the documentation to be regenerated, such as patching gnutls.h.in which I was doing to resolve issue #108614. The error I encountered was:


sed -i 's/\@anchor{.*//g' functions/*
sed: 1: "functions/dane_cert_typ ...": invalid command code f
make[4]: *** [stamp_functions] Error 1


The doc Makefile uses GNU-specific sed features, such as assuming that the argument to the "-i" flag is optional. (In BSD sed, it is required.)

I do actually have GNU sed installed as well, but under the name "gsed" (as provided by the MacPorts "gsed" port). However, although your configure script correctly finds this gsed, your Makefile does not make use of the $SED variable which would have expanded to that program, but instead just uses the program name "sed".

Ideally, your complete build system, including the documentation regeneration, should support both BSD sed and GNU sed. Either stick with just the capabilities that both flavors provide (e.g. always use an argument to "-i", since GNU sed should be happy with that as well), or detect which flavor of BSD is present and change your invocations accordingly at build time.

Ryan Carsten Schmidt <ryandesign>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nmav (Posted a comment)
  • -email is unavailable- added by ryandesign (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-12-12 nmav Open/ClosedOpen Closed
    2014-07-27 nmav StatusNone Done
        Assigned toNone nmav
        Operating SystemNone Mac OS

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code