[gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

It came to my attention during a recent discussion on -core that a
significant number of devs don't have a clue how autotools work and find
any kind of patching that involves tinkering with configure.ac /
Makefile.am level stuff to be very tricky. Clearly, this isn't good,
because a significant number of upstream devs don't have a clue what
they're doing either.

There was already a small autotools explanation in The Doc, but it was
very general. I've added substantially more content to it. Or, at least,
as much as I could think of from my limited experience with autotools.
The results:

http://www.firedrop.org.uk/devmanual/general-concepts/autotools/

What more would people like to see explained? Is there anything in there
that needs changing or clarifying? Anything that's just plain wrong?
Does it need a section on libtool and if so does someone want to explain
to me how the heck it works? Are there good examples of ebuilds which
make understandable changes to these things that I should be adding as
illustrations? Do you like the picture? Feedback please.

I've added, improved and fixed a fair number of other things in other
sections too (some of these thanks to content I've received from other
devs and not-yet-devs), so if your favourite section had a big fat TODO
on it last time you looked it may be worth checking again. And if it
still has a big fat TODO, feel free to contribute :)

http://www.firedrop.org.uk/devmanual/

If anyone wants me to stop talking about my unofficial developer manual
on the official gentoo mailing lists, feel free to say so. Or just
procmail anything containing 'devmanual' in the body.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> http://www.firedrop.org.uk/devmanual/general-concepts/autotools/
> 
> What more would people like to see explained? Is there anything in there
> that needs changing or clarifying? Anything that's just plain wrong?
> Does it need a section on libtool and if so does someone want to explain
> to me how the heck it works? Are there good examples of ebuilds which
> make understandable changes to these things that I should be adding as
> illustrations? Do you like the picture? Feedback please.

I'd like to see a starter on how m4 works. After that, I have a feeling
the rest of the content will be much easier to talk about.

It's also probably worth linking to the autobook for more info.
http://vipe.technion.ac.il/~shlomif/lecture/Autotools/slides/ seems
pretty nice too.

Thanks for your hard work on this!
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCjCPAXVaO67S1rtsRAhLmAJ9oWCUMTGbgnwF8N5fEoNOJNV3rHACffkIN
wvuNX+QsGC/VHaH5H4V/nfQ=
=Ia0a
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Mike Frysinger]

On Wednesday 18 May 2005 11:44 pm, Ciaran McCreesh wrote:
> What more would people like to see explained? Is there anything in there
> that needs changing or clarifying? Anything that's just plain wrong?
> Does it need a section on libtool and if so does someone want to explain
> to me how the heck it works? Are there good examples of ebuilds which
> make understandable changes to these things that I should be adding as
> illustrations? Do you like the picture? Feedback please.

it doesnt cover anything related to older autotools which do not have 
Makefile.am, but i think that's something we can neglect now since the number 
of projects that still just have configure.in/Makefile.in are in decline and 
in low numbers ... i'd point out that some projects (like binutils/gcc) will 
probably never be 'updated', but thankfully the people who work on those 
packages *seem* to know what they're doing

things i'd add:
- make a note at the top that it doesnt matter if the file is configure.in or 
configure.ac, autoconf will act the same ... it's currently hinted at but not 
explicitly mentioned ...
- maybe a section on aclocal and m4 files ... an advanced topic that most 
people shouldnt need to know about ...
- i believe all autotools should be executed in src_unpack() rather than 
src_compile() ... i see unpack as the 'preparation' stage for the 
'compilation' stage of things ...
- there is no 'autoconf-2.5' binary ... there are the perl scripts 
'autoconf-2.13' and 'autoconf-2.59' ...
- when talking about exporting WANT_AUTOMAKE, the usage of 'We can export 
WANT_AUTOMAKE here ...' is a little vague ... it makes it sound like we could 
export it inside the configure.ac rather than when we invoke automake
- WANT_AUTOCONF / WANT_AUTOMAKE are gentooism's that were originally taken 
from Mandrake ... i'm not sure what other distro's use an autotool wrappers, 
but it'd be nice to note this
- library checks are AC_CHECK_LIB while header checks are AC_CHECK_HEADER ...
- maybe set the 3rd parameter of AC_ARG_ENABLE to be enable_cscope=$enableval
- i would add notes under AC_ARG_ENABLE / AC_ARG_WITH that misuse of these 
macros is *very* common due to the confusing description of their 
arguments ... many people think the 3rd/4th arguments correspond with 
enable/disable when in reality they correspond with specified/not 
specified ... ive seen many packages which do:
AC_ARG_ENABLE(blah, [help output], enable_blah=yes, enable_blah=no)
- the most common evil auto check ive seen is when code just does AC_CHECK_LIB 
and then enables/disables support for that library based on the result
- add links to the autobook website (`esearch autobook` for the URL) and links 
to the autoconf/automake/m4 documentation ... i think they all have online 
html versions built off of the bundled docs
- maybe mention that every package which is built on newer autotools (it has a 
Makefile.am and Makefile.in instead of just Makefile.in) should support 
DESTDIR just fine ... if it doesnt, the fault is 99.9% of the time made by 
the package maintainer rather than autotools
- add some notes about how variables in Makefile.{am,in} of the form @VAR@ 
will be expanded if you use the m4 macro AC_SUBST(VAR)

now for long term suggestions:
- develop a reference list of m4 macros since the autobook docs are 
outdated ... have a list that tries to help people who havent worked with 
autotools before ... developer knows they want to verify a header exists or a 
library exists, but they dont know what macro to use
- add a section to cover cross-compile issues ... for example, using 
AC_TRY_RUN is bad manners, even if you do specify a somewhat 'sane' 
default ...
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Mike Frysinger]

On Thursday 19 May 2005 01:43 am, Mike Frysinger wrote:
> - i would add notes under AC_ARG_ENABLE /
> AC_ARG_WITH that misuse of these macros is *very* common

just remembered ... an example of how you can detect that your package may be 
misusing it ...

if you run ./configure --enable-foo, then foo will be enabled ... but if you 
run ./configure --disable-foo, foo will still be enabled ... only way to not 
get foo to be enabled is to simply run ./configure
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Mike Frysinger]

On Wednesday 18 May 2005 11:44 pm, Ciaran McCreesh wrote:
> What more would people like to see explained?

might be useful to have a brief 'syntax' section ... one that covers different 
'features' of the m4 language ...

for example, [] are used for quotes and if you try to use "", they are 
actually passed through ...
AC_MSG_RESULT([eat me])
AC_MSG_RESULT("eat me")

the second one will actually output the quotes which is often unexpected 
behavior for many new autotool hackers
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Stephen Bennett]

On Thu, 2005-05-19 at 04:44 +0100, Ciaran McCreesh wrote:
> Do you like the picture? Feedback please.

I do like the picture. It's a very pretty picture.

However, some explanation of libtool would be nice, if only because it's
so good at breaking in new and inventive ways.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Chris White]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> It came to my attention during a recent discussion on -core that a
> significant number of devs don't have a clue how autotools work and find
> any kind of patching that involves tinkering with configure.ac /
> Makefile.am level stuff to be very tricky. Clearly, this isn't good,
> because a significant number of upstream devs don't have a clue what
> they're doing either.
> 
> I've added, improved and fixed a fair number of other things in other
> sections too (some of these thanks to content I've received from other
> devs and not-yet-devs), so if your favourite section had a big fat TODO
> on it last time you looked it may be worth checking again. And if it
> still has a big fat TODO, feel free to contribute :)

Another thing I'd mention too is that one can also check configure.ac to
check requirements for the package (use flags as well).  I've seen one
too many pages where maintainers list a small number of deps, and after
reading the configure.ac file, find a ton more.  Examples as follows:


      AM_PATH_LIBFAME(0.8.10,
        AC_DEFINE(HAVE_NEW_LIBFAME,1,[Define this if you have libfame
0.8.10 or above]))

This tells us that we need libfame >=0.8.10 .  Therefore, in our deps
section, we know to have >=media-libs/libfame-0.8.10 .  You can also
check for things that need other support enabled.  For example:

AC_MSG_CHECKING(for vidix support)
if test x"$check_vidix" = "xyes" -a x"$ac_cv_prog_AWK" != "xno"; then
  if test x"$no_x" != "xyes" -o x"$have_fb" = "xyes"; then
    case "$host_or_hostalias" in
      i?86-*-linux* | k?-*-linux* | athlon-*-linux*)
        enable_vidix="yes"
        enable_linux="yes"
        ;;
      i386-*-freebsd*)
        enable_vidix="yes"
        enable_dha_kmod="no"
        ;;
      *)
        enable_dha_kmod="no"
        enable_vidix="no"
        ;;
    esac
  fi
fi

If you don't have x or framebuffer enabled, vidix doesn't work.
Sometimes, there's other ways that things are checked for besides
libraries.  As shown here:

AC_CHECK_LIB(mng, mng_initialize,
        [ AC_CHECK_HEADER(libmng.h,
                [ have_libmng=yes
                  MNG_LIBS="-lmng" ],
                AC_MSG_RESULT([*** All libmng dependent parts will be
disabled ***]))],
        AC_MSG_RESULT([*** All libmng dependent parts will be disabled
***]))
AM_CONDITIONAL(HAVE_LIBMNG, test x"$have_libmng" = "xyes")
AC_SUBST(MNG_LIBS)

The configure script will check for libmng.h and run off of that.
You're probably going to need to patch that.. because if the script's
lib checking functionality isn't lib64 friendly, you're gonna see a
whole world of chaos.  So basically, check stuff like that out.
Sometimes however, you're going to get stuff that you can only check by
header.  Most of the time it's kernel/system based.  For example:

AC_MSG_CHECKING(for Sun audio support)
have_sunaudio=no
AC_TRY_COMPILE([
            #include <sys/types.h>
            #include <sys/audioio.h>
        ],[
            audio_info_t audio_info;
            AUDIO_INITINFO(&audio_info);
        ],[
            have_sunaudio=yes
        ])
AC_MSG_RESULT($have_sunaudio)
AM_CONDITIONAL(HAVE_SUNAUDIO, test x"$have_sunaudio" = "xyes")

Can only check for sun audio by testing kernel headers.  There's no real
library.  Looking out for stuff like this is a real big help to figuring
out what on earth your package needs.

Chris White
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFCjNKoFdQwWVoAgN4RArwWAKC2l9NppEReMPWEmqd6xpAPchTC9gCgiIYN
3ezPqSvy5vJBtM3Gaeu3ZUs=
=TKT3
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Mike Frysinger]

On Thursday 19 May 2005 01:53 pm, Chris White wrote:
> AC_CHECK_LIB(mng, mng_initialize,
>         [ AC_CHECK_HEADER(libmng.h,
>                 [ have_libmng=yes
>                   MNG_LIBS="-lmng" ],
>                 AC_MSG_RESULT([*** All libmng dependent parts will be
> disabled ***]))],
>         AC_MSG_RESULT([*** All libmng dependent parts will be disabled
> ***]))
> AM_CONDITIONAL(HAVE_LIBMNG, test x"$have_libmng" = "xyes")
> AC_SUBST(MNG_LIBS)
>
> The configure script will check for libmng.h and run off of that.
> You're probably going to need to patch that.. because if the script's
> lib checking functionality isn't lib64 friendly, you're gonna see a
> whole world of chaos.

this is a good example of how a package detects libmng at configure time, but 
doesnt allow you to explicitly control enabling/disabling

but to address the lib64 issue ... i dont see how this block of code has to 
care even 1 bit about the library paths on the system ... AC_CHECK_HEADER 
will simply create a small C file with '#include <libmng.h>' and then try to 
compile it ... then if it works, it will add '-lmng' to LDFLAGS ...

how does linking paths come into play at all in this example ?  here the 
script will simply let the compiler use its own judgment in locating a 
suitable candidate for '-lmng'
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Mike Frysinger]

On Thursday 19 May 2005 02:59 pm, Mike Frysinger wrote:
> then if it works, it will add '-lmng' to LDFLAGS ...

err, no it doesnt ... it adds -lmng to MNG_LIBS which is updated in Makefile's 
with AC_SUBST() ...
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Chris White]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Frysinger wrote:
> On Thursday 19 May 2005 02:59 pm, Mike Frysinger wrote:
> 
>>then if it works, it will add '-lmng' to LDFLAGS ...
> 
> 
> err, no it doesnt ... it adds -lmng to MNG_LIBS which is updated in Makefile's 
> with AC_SUBST() ...
> -mike

I meant to say it adds it to the linking flags when mng is needed.  That
wasn't quite what came out..

does this mean I'm FACED?

Chris White
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFCjO09FdQwWVoAgN4RAtQfAJ9IxJegWQZZciXb5cVL3HqOhrdnqACgzBkG
BX/rSl0vp7fpw5kFE+d/NAY=
=rbS8
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Mike Frysinger]

On Thursday 19 May 2005 03:47 pm, Chris White wrote:
> Mike Frysinger wrote:
> > On Thursday 19 May 2005 02:59 pm, Mike Frysinger wrote:
> >>then if it works, it will add '-lmng' to LDFLAGS ...
> >
> > err, no it doesnt ... it adds -lmng to MNG_LIBS which is updated in
> > Makefile's with AC_SUBST() ...
> > -mike
>
> I meant to say it adds it to the linking flags when mng is needed.  That
> wasn't quite what came out..
>
> does this mean I'm FACED?

it certainly does, deal with it
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

On Thu, 19 May 2005 04:44:25 +0100 Ciaran McCreesh <ciaranm@gentoo.org>
wrote:
| http://www.firedrop.org.uk/devmanual/general-concepts/autotools/

Updated based upon the feedback, thanks guys. If someone who's
relatively clueless about autotools could give it a read and let me know
what is and isn't clear I'd appreciate it.

There're still lots of things that could be improved, of course, but I
reckon it's probably more helpful if I start tidying up other areas some
more rather than spending huge amounts of time getting that one page
perfect.

Oh, I killed the yellow/purple. And updated the picture!

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 2265 bytes --]

maillog: 20/05/2005-06:06:21(+0100): Ciaran McCreesh types
> On Thu, 19 May 2005 04:44:25 +0100 Ciaran McCreesh <ciaranm@gentoo.org>
> wrote:
> | http://www.firedrop.org.uk/devmanual/general-concepts/autotools/
> 
> Updated based upon the feedback, thanks guys. If someone who's
> relatively clueless about autotools could give it a read and let me know
> what is and isn't clear I'd appreciate it.

That would be me.

Notes:

- typo?
	- The configure script is run to produce one or Makefile files from Makefile.in files.
	+ The configure script is run to produce one or more Makefile files from Makefile.in files.

- clarification

	AC_MSG_CHECKING(--enable-cscope argument)
	AC_ARG_ENABLE(cscope,
		[  --enable-cscope         Include cscope interface.],
		[enable_cscope=$enableval],
		[enable_cscope="no"])
	AC_MSG_RESULT($enable_cscope)
	if test "$enable_cscope" = "yes"; then
	  AC_DEFINE(FEAT_CSCOPE)
	fi

	<1 paragraph skipped>

	Important: The third argument is used when an option is
	specified, and the fourth is used when an option is not
	specified. A common misconception is that the third is enable
	and the fourth is disable — this is not the case.  You may
	encounter packages that get this wrong.

The phrase "when an option is specified" is a bit ambiguous, especially
since it is later referred by the explanation of AC_ARG_WITH. I was not
sure if "option" in this case means "option" as in
"--enable-foo=OPTION". I was confused, because one paragarph before the
example you talk about "--enable-foo and --disable-foo *switches* to
./configure".

Maybe the above can be written as: ‟The third argument is used when
either "--enable" or "--disable" is specified, and the fourth is used
when neither is specified.” Or you could simply stick to using
"switches" instead of "options"?

- coloring

	%.1 : %.in
		@regex_cmd@ -e "s,\@VERSION\@,$(VERSION),g" $? > $@

The first "@" is span.Special and the second one is span.Constant.

Good job by the way.

-- 
()   Georgi Georgiev   () There is only one thing in the world worse   ()
()    chutz@gg3.net    () than being talked about, and that is not     ()
()  +81(90)2877-8845   () being talked about. -- Oscar Wilde           ()

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]

On Fri, 20 May 2005 15:06:12 +0900 Georgi Georgiev <chutz@gg3.net>
wrote:
| 	- The configure script is run to produce one or Makefile files
| 	from Makefile.in files.
|       + The configure script is run to produce
| 	one or more Makefile files from Makefile.in files.

Gah! I'm sure I'd already fixed that one...

| The phrase "when an option is specified" is a bit ambiguous,
| especially since it is later referred by the explanation of
| AC_ARG_WITH. I was not sure if "option" in this case means "option" as
| in "--enable-foo=OPTION". I was confused, because one paragarph before
| the example you talk about "--enable-foo and --disable-foo *switches*
| to ./configure".

.. Important:: The third argument is used when a ``--enable`` or
  ``--disable`` switch to ``./configure`` is provided, and the fourth
  is used when such a switch is *not* passed. A common misconception is
  that the third is enable and the fourth is disable -- this is **not**
  the case. You may encounter packages that get this wrong.

Does that sound any better?

| - coloring
| 
| 	%.1 : %.in
| 		@regex_cmd@ -e "s,\@VERSION\@,$(VERSION),g" $? > $@
| 
| The first "@" is span.Special and the second one is span.Constant.

Hrm, that's a vim thing (I'm using a vim script to do the highlighting
at compile time, it's not manual). If someone enjoys pain they could
have a go at making vim's automake highlighting smarter... Don't think
I'm brave enough to touch that one myself.

Thanks,
-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]

maillog: 20/05/2005-07:22:15(+0100): Ciaran McCreesh types
> On Fri, 20 May 2005 15:06:12 +0900 Georgi Georgiev <chutz@gg3.net> wrote:
> | The phrase "when an option is specified" is a bit ambiguous,
> | especially since it is later referred by the explanation of
> | AC_ARG_WITH. I was not sure if "option" in this case means "option" as
> | in "--enable-foo=OPTION". I was confused, because one paragarph before
> | the example you talk about "--enable-foo and --disable-foo *switches*
> | to ./configure".
> 
> .. Important:: The third argument is used when a ``--enable`` or
>   ``--disable`` switch to ``./configure`` is provided, and the fourth
>   is used when such a switch is *not* passed. A common misconception is
>   that the third is enable and the fourth is disable -- this is **not**
>   the case. You may encounter packages that get this wrong.
> 
> Does that sound any better?

Yes, much better.

> | - coloring
> | 
> | 	%.1 : %.in
> | 		@regex_cmd@ -e "s,\@VERSION\@,$(VERSION),g" $? > $@
> | 
> | The first "@" is span.Special and the second one is span.Constant.
> 
> Hrm, that's a vim thing (I'm using a vim script to do the highlighting
> at compile time, it's not manual). If someone enjoys pain they could
> have a go at making vim's automake highlighting smarter... Don't think
> I'm brave enough to touch that one myself.

The 2html.vim that comes with vim seems to work fine here. Tried both 7α
and 6.3. The HTML is ugly, but at least it's properly highlighted:

http://gg3.net/~chutz/gentoo/highlight/

Of course, you need to "set ft=automake", which is different than
ft=make. ;)

$ vim -c 'set ft=automake' Makefile.in -c TOhtml -c wq -c qa

-- 
 /   Georgi Georgiev    / Harp not on that string. -- William           /
\     chutz@gg3.net    \  Shakespeare, "Henry VI"                      \
 /  +81(90)2877-8845    /                                               /

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

On Fri, 20 May 2005 18:01:04 +0900 Georgi Georgiev <chutz@gg3.net>
wrote:
| > | 	%.1 : %.in
| > | 		@regex_cmd@ -e "s,\@VERSION\@,$(VERSION),g" $? > $@
| > | 
| > | The first "@" is span.Special and the second one is span.Constant.
| > 
| > Hrm, that's a vim thing (I'm using a vim script to do the
| > highlighting at compile time, it's not manual). If someone enjoys
| > pain they could have a go at making vim's automake highlighting
| > smarter... Don't think I'm brave enough to touch that one myself.
| 
| The 2html.vim that comes with vim seems to work fine here. Tried both
| 7__ and 6.3. The HTML is ugly, but at least it's properly highlighted:
| 
| http://gg3.net/~chutz/gentoo/highlight/
| 
| Of course, you need to "set ft=automake", which is different than
| ft=make. ;)

That's only working because you're indenting using spaces rather than
tabs. If you indent using tabs you'll get the mixed colouring.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 2277 bytes --]

maillog: 20/05/2005-10:29:53(+0100): Ciaran McCreesh types
> On Fri, 20 May 2005 18:01:04 +0900 Georgi Georgiev <chutz@gg3.net>
> wrote:
> | > | 	%.1 : %.in
> | > | 		@regex_cmd@ -e "s,\@VERSION\@,$(VERSION),g" $? > $@
> | > | 
> | > | The first "@" is span.Special and the second one is span.Constant.
> | > 
> | > Hrm, that's a vim thing (I'm using a vim script to do the
> | > highlighting at compile time, it's not manual). If someone enjoys
> | > pain they could have a go at making vim's automake highlighting
> | > smarter... Don't think I'm brave enough to touch that one myself.
> | 
> | The 2html.vim that comes with vim seems to work fine here. Tried both
> | 7__ and 6.3. The HTML is ugly, but at least it's properly highlighted:
> | 
> | http://gg3.net/~chutz/gentoo/highlight/
> | 
> | Of course, you need to "set ft=automake", which is different than
> | ft=make. ;)
> 
> That's only working because you're indenting using spaces rather than
> tabs. If you indent using tabs you'll get the mixed colouring.

Owwww, so true, so true...

I am trying to redeem myself with the following. Care to give it a try?

--- /usr/share/vim/vim70aa/syntax/automake.vim.old      2005-05-20 19:05:09.000000000 +0900
+++ /usr/share/vim/vim70aa/syntax/automake.vim  2005-05-20 19:07:05.000000000 +0900
@@ -43,6 +43,7 @@
 syn region  automakeMakeDString start=+"+  skip=+\\"+  end=+"+  contains=makeIdent,automakeSubstitution
 syn region  automakeMakeSString start=+'+  skip=+\\'+  end=+'+  contains=makeIdent,automakeSubstitution
 syn region  automakeMakeBString start=+`+  skip=+\\`+  end=+`+  contains=makeIdent,makeSString,makeDString,makeNextLine,automakeSubstitution
+syn region makeCommands start=";"hs=s+1 start="^\t" end="^[^\t#]"me=e-1,re=e-1 end="^$" contained contains=makeCmdNextLine,makeSpecial,makeComment,makeIdent,makePreCondit,makeDefine,makeDString,makeSString,autoMakeSubst,automakeMakeError,automakeBadSubst nextgroup=makeCommandError
 
 " Define the default highlighting.
 " For version 5.7 and earlier: only when not done already

-- 
/\   Georgi Georgiev   /\ Be not anxious about what you have, but      /\
\/    chutz@gg3.net    \/ about what you are. -- Pope St. Gregory I    \/
/\  +81(90)2877-8845   /\                                              /\

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

On Fri, 20 May 2005 19:11:13 +0900 Georgi Georgiev <chutz@gg3.net>
wrote:
| Owwww, so true, so true...
| 
| I am trying to redeem myself with the following. Care to give it a
| try?

Pretty close, thanks. I think I'll adapt it a bit to define a cluster in
make.vim and then add to that cluster in automake.vim rather than just
overriding the entire rule. That way if make.vim is ever updated we'll
either carry on working or get a nice visible patch failure rather than
silent weirdness. Bug 93378 if you want to track it.

I'll be doing new vim6 and 7 snapshots soon from the looks of things, so
I'll include it then.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

maillog: 20/05/2005-18:01:04(+0900): Георги Георгиев types
> maillog: 20/05/2005-07:22:15(+0100): Ciaran McCreesh types
> > Hrm, that's a vim thing (I'm using a vim script to do the highlighting
> > at compile time, it's not manual). If someone enjoys pain they could
> > have a go at making vim's automake highlighting smarter... Don't think
> > I'm brave enough to touch that one myself.
> 
> The 2html.vim that comes with vim seems to work fine here. Tried both 7α
> and 6.3. The HTML is ugly, but at least it's properly highlighted:
> 
> http://gg3.net/~chutz/gentoo/highlight/
> 
> Of course, you need to "set ft=automake", which is different than
> ft=make. ;)
> 
> $ vim -c 'set ft=automake' Makefile.in -c TOhtml -c wq -c qa

Taking back my words about the ugly HTML. I just met html_use_css.

vim -c 'set ft=automake' -c 'let use_xhtml=1' -c 'let html_use_css=1' \
	-c TOhtml -c wq -c qa Makefile.in

-- 
(    Georgi Georgiev   (  heavy, adj.: Seduced by the chocolate side   (
 )    chutz@gg3.net     ) of the force.                                 )
(   +81(90)2877-8845   (                                               (

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]