David Lawrence Ramsey | 1 Sep 2004 16:31

Re: useless include ?

--- Mike Frysinger <vapier <at> gentoo.org> wrote:
>On Monday 30 August 2004 12:08 pm, David Lawrence Ramsey wrote:
>> If I understand it correctly, it's there so that the --includedir 
>> option of the configure script will be used.  It's /usr/local/include 
>> by default, but e.g. "./configure --includedir=/some/directory" will 
>> set the include path to /some/directory/include.
>
>the --includedir configure option is supposed to be for install/runtime 
>control, not for additional include paths at build time

Okay; obviously I didn't quite understand it correctly.  I tried
compiling nano after removing the  <at> includedir <at>  option from
src/Makefile.am, and it seemed to build just fine, but I wanted to be
sure that I wasn't removing something that should have been there.  So I
guess that it can be safely removed then?

By the way, by install/runtime control, do you mean that it's supposed 
to be used for e.g. libraries that install their own header files?  If 
so, then it really needs to be removed, since nano certainly isn't one 
of those.

>that really should be set by export CFLAGS before running ./configure, 
>or what ive seen with a few autotool based projects is a parameter 
>specifically for adding include paths

Exporting CFLAGS should definitely work.  "./configure --help" also says
that you can do it by exporting CPPFLAGS.  As for adding a parameter
specifically for adding include paths, that seems like overkill to me
because it's only really needed to get access to the main include files.
(Continue reading)

Mike Frysinger | 1 Sep 2004 16:59
Picon
Favicon
Gravatar

Re: useless include ?

On Wednesday 01 September 2004 10:31 am, David Lawrence Ramsey wrote:
> but I wanted to be
> sure that I wasn't removing something that should have been there.  So I
> guess that it can be safely removed then?

i dont know what failures you saw in the past but, afaik, all standard gcc 
packages have /usr/include and /usr/local/include in their default search 
paths (or equivalent paths depending on your install)

> By the way, by install/runtime control, do you mean that it's supposed
> to be used for e.g. libraries that install their own header files?  If
> so, then it really needs to be removed, since nano certainly isn't one
> of those.

yes, that's what i mean ... for example, xine-lib would use it to determine 
where the user wants to install xine.h and then it would make sure that 
`xine-config --cflags` had the write info for apps that use xine ...

> Exporting CFLAGS should definitely work.  "./configure --help" also says
> that you can do it by exporting CPPFLAGS.

true ... i always forget about CPPFLAGS ... few people ever use it :)
but in this case, you're write ... CPPFLAGS should define the extraneous 
include paths
-mike
Mike Frysinger | 1 Sep 2004 17:36
Picon
Favicon
Gravatar

Re: useless include ?

On Wednesday 01 September 2004 10:59 am, Mike Frysinger wrote:
> write

err, s/write/right/

speaking of regexs ... does anyone know how to make a rule in nanorc's syntax 
highlighting to match whitespace ?  i can match spaces just fine but i want 
the rule to match leading spaces and tabs ...
-mike
David Lawrence Ramsey | 2 Sep 2004 16:04

Re: useless include ?

--- Mike Frysinger <vapier <at> gentoo.org> wrote:
>i dont know what failures you saw in the past but, afaik, all standard 
>gcc packages have /usr/include and /usr/local/include in their default 
>search paths (or equivalent paths depending on your install)

That's good.  I haven't actually seen any failures; I'm just a bit 
paranoid about breaking the build.  In any case,  <at> includedir <at>  has now 
been removed in CVS.  The attached patch is a backport of it to 1.3.4.
diff -ur nano-1.3.4/src/Makefile.am nano-1.3.4-fixed/src/Makefile.am
--- nano-1.3.4/src/Makefile.am	2004-08-17 23:31:25.000000000 -0400
+++ nano-1.3.4-fixed/src/Makefile.am	2004-09-01 17:18:55.000000000 -0400
 <at>  <at>  -1,6 +1,6  <at>  <at> 
 DEFS= -DSYSCONFDIR=\"$(sysconfdir)\"
 localedir = $(datadir)/locale
-INCLUDES = -Iintl -DLOCALEDIR=\"$(localedir)\" -I <at> includedir <at> 
+INCLUDES = -Iintl -DLOCALEDIR=\"$(localedir)\"

 ACLOCAL_AMFLAGS = -I m4

_______________________________________________
Nano-devel mailing list
Nano-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/nano-devel
Mike Frysinger | 2 Sep 2004 16:43
Picon
Favicon
Gravatar

Re: useless include ?

On Thursday 02 September 2004 10:04 am, David Lawrence Ramsey wrote:
> That's good.  I haven't actually seen any failures; I'm just a bit
> paranoid about breaking the build.  In any case,  <at> includedir <at>  has now
> been removed in CVS.  The attached patch is a backport of it to 1.3.4.

thanks :)
while we're on the subject, would you consider defining the 4th parameter in 
each of the AC_TRY_RUN() macro's ?  right now they all define the 1st, 2nd, 
and 3rd parameters, but not the 4th ...
it would make cross compiling nano a non-issue then :)
-mike
David Lawrence Ramsey | 6 Sep 2004 17:03

Re: useless include ?

--- Mike Frysinger <vapier <at> gentoo.org> wrote:
>On Thursday 02 September 2004 10:04 am, David Lawrence Ramsey wrote:
>> That's good.  I haven't actually seen any failures; I'm just a bit 
>> paranoid about breaking the build.  In any case,  <at> includedir <at>  has now 
>> been removed in CVS.  The attached patch is a backport of it to 
>> 1.3.4.
>
>thanks :) while we're on the subject, would you consider defining the 
>4th parameter in each of the AC_TRY_RUN() macro's ?  right now they all 
>define the 1st, 2nd, and 3rd parameters, but not the 4th ... it would 
>make cross compiling nano a non-issue then :)

I've done it for the first one (the broken regexec() check) in the 
attached patch.  I'm assuming "no" because as far as I know, the bug 
appears to only be in glibc 2.2.3, so just make sure you're not using 
that on the system you're building for.

I've looked at the others, though, and it appears that there are already 
warnings about trying to use slang when cross-compiling as the fourth 
parameter in the next AC_TRY_RUN().  Do they handle things properly, or 
not?  I only ask because there are AC_TRY_RUN()s within AC_TRY_RUN()s 
there, and I'm not entirely sure how it all works when only the 
outermost one has a warning.
diff -ur nano/configure.ac nano-fixed/configure.ac
--- nano-1.3.4/configure.ac	2004-08-17 16:44:31.000000000 -0400
+++ nano-1.3.4-fixed/configure.ac	2004-09-04 17:01:40.000000000 
-0400
 <at>  <at>  -56,7 +56,9  <at>  <at> 
(Continue reading)

Mike Frysinger | 6 Sep 2004 23:35
Picon
Favicon
Gravatar

Re: useless include ?

On Monday 06 September 2004 11:03 am, David Lawrence Ramsey wrote:
> I've looked at the others, though, and it appears that there are already
> warnings about trying to use slang when cross-compiling as the fourth
> parameter in the next AC_TRY_RUN().  Do they handle things properly, or
> not?  I only ask because there are AC_TRY_RUN()s within AC_TRY_RUN()s
> there, and I'm not entirely sure how it all works when only the
> outermost one has a warning.

the first parameter to AC_TRY_RUN() would never be utilized in a 
cross-compiling scenario ... so if you have nested AC_TRY_RUN()'s in the 
first param, you can just 'ignore' them ... add the 4th parameter to the 
first AC_TRY_RUN() and everything should be golden

personally i dislike slang intensely so i just always disable it :)
-mike
Trevor Lalish-Menagh | 8 Sep 2004 11:38

Some useful .nanorc scripts

Hi guys,

I just thought I would post a couple useful scripts I use to change my 
.nanorc settings on the fly:
----
#!/bin/ksh

# Make a backup in case we mess up
cp ~/.nanorc ~/.nanorcbackup

if [[ $(grep -c '^set nowrap' ~/.nanorc) != 0 ]] ; then
         sed s/"^set nowrap"/"\#set nowrap"/g ~/.nanorc >temp
   print WordWrap ON
else
         sed s/"\#set nowrap"/"set nowrap"/g ~/.nanorc >temp
   print WordWrap OFF
fi

mv temp ~/.nanorc
----
and
----
#!/bin/ksh

# Make a backup in case we mess up
cp ~/.nanorc ~/.nanorcbackup

if [[ $(grep -c '^set autoindent' ~/.nanorc) != 0 ]] ; then
         sed s/"^set autoindent"/"\#set autoindent"/g ~/.nanorc >temp
   print AutoIndent OFF
(Continue reading)

Jean-Philippe Guérard | 8 Sep 2004 14:07
Favicon

Re: French man pages for nano 1.34

Hello !

Here is a slightly updated version of the 2 nano French manpages,
following a proofreading by Gerard Delafond.

Thanks !

-- 
Jean-Philippe Guérard
http://tigreraye.org
.\" Hey, EMACS: -*- nroff -*-
.\" nano.1 is copyright (C) 1999, 2000, 2001, 2002, 2003 by
.\" Chris Allegretta <chrisa <at> asty.org>
.\"
.\" (c) 2003-2004 Jean-Philippe Guérard <jean-philippe.guerard <at> corbeaunoir.org>
.\" pour l'adaptation française
.\"
.\" This is free documentation, see the latest version of the GNU General
.\" Public License for copying conditions.  There is NO warranty.
.\"
.\" Ce document est libre. Reportez-vous à la dernière version de la
.\" licence publique générale GNU (GNU GPL) pour connaître ses
.\" conditions d'utilisation. AUCUNE garantie n'est offerte.
.\"
.\" $Id: nano.1,v 1.13 2004/08/17 20:38:44 dolorous Exp $
.TH NANO 1 "version 1.3.4" "17 août 2004"  
.\" Please adjust this date whenever revising the manpage.
.\" Merci de modifier ces dates à chaque mise à jour de cette page.
(Continue reading)

David Lawrence Ramsey | 10 Sep 2004 19:00

Re: useless include ?

Sorry for the delay in responding; I've been busy.

--- Mike Frysinger <vapier <at> gentoo.org> wrote:

<snip>

>the first parameter to AC_TRY_RUN() would never be utilized in a 
>cross-compiling scenario ... so if you have nested AC_TRY_RUN()'s in 
>the first param, you can just 'ignore' them ... add the 4th parameter 
>to the first AC_TRY_RUN() and everything should be golden

Okay; thanks for the info.  The fourth parameter of the first 
AC_TRY_RUN() is indeed set in the last patch I sent you (which is now in 
CVS), but the nested AC_TRY_RUN()s are in the second parameter, since 
they're run only if the test in the first parameter fails.  Is that 
golden too?

>personally i dislike slang intensely so i just always disable it :)

I don't like it much myself either.

Gmane