Hello Werner,
Sorry for my late answer, I was a bit busy these days.
On Thu, Nov 13 2014 at 08:46:21 PM, Werner LEMBERG wrote:
>> I've just fully rebased `automake3', and I think it is nearly ready
>> to be merged into master.
>
> Great!
>
>> - An entry in `NEWS' should also be added.
>
> Why?
> I've just fully rebased `automake3', and I think it is nearly ready
> to be merged into master.
Great!
> - An entry in `NEWS' should also be added.
Why? Is there any change for the user?
Werner
Hi all,
> On Wed, Oct 08 2014 at 11:34:26 AM, Werner LEMBERG wrote:
>>> Also, how will we proceed when we will consider that this automake
>>> migration is ready for merge into master? The normal process would
>>> be to squash all the commits into a single one on master, but given
>>> the high n
>> OK. s/daily/commit/.
>
> That looks good. The same change should still be made in
> doc/webpage.ms, too.
Fixed, thanks.
Werner
On 10/18/14, Werner LEMBERG wrote:
>> It's my understanding that one can get a snapshot from git based on
>> a commit (the README explains how earlier in the file), but that
>> *daily* snapshots are no longer being generated.
>
> OK. s/daily/commit/.
That looks good. The same change should sti
> It's my understanding that one can get a snapshot from git based on
> a commit (the README explains how earlier in the file), but that
> *daily* snapshots are no longer being generated.
OK. s/daily/commit/.
Werner
On 10/16/14, Werner LEMBERG wrote:
>> README:
>>
>> contains one reference to a "daily snapshot."
>
> This one is correct.
It's my understanding that one can get a snapshot from git based on a
commit (the README explains how earlier in the file), but that *daily*
snapshots are no longer being gen
> src/roff/groff/groff.man:
>
> The most recent released version of
> .I groff
> is available at the
> .UR http://\:groff.ffii.org/\:groff/\:devel/\:groff-current.tar.gz
> groff development site
> .UE .
I've removed this paragraph.
> doc/webpage.ms:
>
> This docum
Hi Werner,
Werner LEMBERG wrote on Wed, Oct 15, 2014 at 05:28:47PM +0200:
>> In the GNU/Linux world, many systems (apart from the kernel and
>> maybe the coreutils and maybe a very small number of other
>> components) consist of a variable set of packages, and each
>> distribution, and to a certa
> In the GNU/Linux world, many systems (apart from the kernel and
> maybe the coreutils and maybe a very small number of other
> components) consist of a variable set of packages, and each
> distribution, and to a certain extent each user, is free to assemble
> their system from whatever component
Hi Werner,
Werner LEMBERG wrote on Thu, Sep 25, 2014 at 11:35:26AM +0200:
> Ingo Schwarze wrote:
>> - it prefers /usr/local/bin/gsed over /usr/bin/sed
>> - it prefers /usr/local/bin/bison over /usr/bin/yacc
>>
>> Prefering the GNU versions over the native POSIX versions
>> is bad because it ca
Werner,
On Wed, Oct 08 2014 at 11:34:26 AM, Werner LEMBERG wrote:
>> Also, how will we proceed when we will consider that this automake
>> migration is ready for merge into master? The normal process would
>> be to squash all the commits into a single one on master, but given
>> the high number
> Also, how will we proceed when we will consider that this automake
> migration is ready for merge into master? The normal process would
> be to squash all the commits into a single one on master, but given
> the high number of files impacted, it might be better to have all
> the commits into ma
Hi all,
On Sat, Oct 04 2014 at 01:37:44 AM, Bertrand Garrigues
wrote:
> On Fri, Oct 03 2014 at 06:44:34 AM, Werner LEMBERG wrote:
>> Looks good, thanks a lot! I've just minor comments, see below.
>> Please commit.
>
> Commited with your fixes on master. I'll cherry-pick this commit on
> autom
Hi Bertrand,
> Also, isn't groff by default displaying a single space after a full
> stop ?
If only one is entered, yes.
$ nroff
.pl 1
Foo.
Bar. Xyzzy. The end. P.S.\&
Just one.
^D
Foo. Bar. Xyzzy. The end. P.S. Just one.
$
The end of a sentence at t
> [...] I too miss a request like LaTeXs \frenchspacing in groff. It
> is tedious to always type \& after each full stop
Say
.nr .sss-orig \n[.sss]
.ss \n[.ss] 0
...
your text
...
.ss \n[.ss] \n[.sss-orig]
if you want to retain the original \n[.sss] value. Otherwise, simply
> So If I understand correctly the format:
> - First you put a title or sum up and general explanations.
First, you should have a single line (not longer than 78 chars) that
describes the issue – this is mainly for programs like `gitk', which
shows a summary of commits in its main window.
Then
Clarke Echols wrote:
> On 10/03/2014 05:37 PM, Bertrand Garrigues wrote:
>
> > It's OK for me to use 2 spaces after a full sentence. But I'm not used
> > to it, I've always been taught to use a single-space after a full stop
> > (French spacing ?!). I've just noticed that a lot of people on
Werner,
On Sat, Oct 04 2014 at 07:38:39 PM, Werner LEMBERG wrote:
> Thanks, nice try, but completely wrong format :-)
Sorry...
> Please *exactly* follow the rules as laid out in previous entries in
> this file.
So If I understand correctly the format:
- First you put a title or sum up and gene
> I completely forgot the ChangeLog... Commited.
Thanks, nice try, but completely wrong format :-)
Please *exactly* follow the rules as laid out in previous entries in
this file.
I've fixed it for you.
Werner
Werner,
On Sat, Oct 04 2014 at 08:26:49 AM, Werner LEMBERG wrote:
>>> Please use two spaces after a full sentence stop.
>>
>> It's OK for me to use 2 spaces after a full sentence. But I'm not used
>> to it, I've always been taught to use a single-space after a full stop
>> (French spacing ?!).
Werner,
On Sat, Oct 04 2014 at 04:53:37 PM, Werner LEMBERG wrote:
> Ah, I've missed that there is no ChangeLog entry yet. Please add one
> for your last commit.
I completely forgot the ChangeLog... Commited.
Regards,
--
Bertrand Garrigues
>> Commited with your fixes on master.
>
> Thanks!
Ah, I've missed that there is no ChangeLog entry yet. Please add one
for your last commit.
Werner
> Commited with your fixes on master.
Thanks!
>> Please use two spaces after a full sentence stop.
>
> It's OK for me to use 2 spaces after a full sentence. But I'm not used
> to it, I've always been taught to use a single-space after a full stop
> (French spacing ?!). I've just noticed that
On 04/10/14 12:17:48, Denis M. Wilson wrote:
This expands on what Clarke says --- it's not just in the USA, but
other English speaking dialects. What have other Western language
authors have to say about this decline?
Good afternoon Denis,
I assume English as she is spoke & writ in Austral
It's really off topic, but in the UK in the 1980s, the printers strike
meant the the end of expert typography. The hot metal traditional
expert typography was replaced by crumbly computer software and 500
years of the art and craft of it was lost --- well it was still there
but unknown to the perso
> On 10/03/2014 05:37 PM, Bertrand Garrigues wrote:
> > ... I've just noticed that a lot of people on the list
> > use 2 spaces after a full stop. What is the main reason ? ...
On Fri, Oct 03, 2014 at 06:54:51PM -0600, Clarke Echols wrote:
> :
> I find it easier to read because I read fas
On 10/03/2014 05:37 PM, Bertrand Garrigues wrote:
It's OK for me to use 2 spaces after a full sentence. But I'm not used
to it, I've always been taught to use a single-space after a full stop
(French spacing ?!). I've just noticed that a lot of people on the list
use 2 spaces after a full st
Hi Werner,
On Fri, Oct 03 2014 at 06:44:34 AM, Werner LEMBERG wrote:
> Looks good, thanks a lot! I've just minor comments, see below.
> Please commit.
Commited with your fixes on master. I'll cherry-pick this commit on
automake2 soon (I have to fix some comments in the `TESTS' file). After
th
Looks good, thanks a lot! I've just minor comments, see below.
Please commit.
Werner
==
> +o X11 resources for gxditview, that were previously installed in
I think this should be `
Hello Werner,
On Tue, Sep 30 2014 at 08:02:24 AM, Werner LEMBERG wrote:
>> -> So, should I try to support this old behavior (looking for
>> libX11), or should I directly write something very simple, like
>> looking for app-defaults in a few defaults directory like
>> /usr/share/X11, /usr/li
> -> So, should I try to support this old behavior (looking for
> libX11), or should I directly write something very simple, like
> looking for app-defaults in a few defaults directory like
> /usr/share/X11, /usr/lib/X11, /etc/X11 (this was my first
> intention) ? Note that the possibility
Werner,
On Mon, Sep 29 2014 at 04:55:16 PM, Werner LEMBERG wrote:
>> As long as we keep the --with-appresdir option, packagers would not
>> have extra work. As said previously, Arch linux uses
>> --with-appresdir=/usr/share/X11/app-defaults, and it seems that
>> Debian (https://packages.debian.or
> As long as we keep the --with-appresdir option, packagers would not
> have extra work. As said previously, Arch linux uses
> --with-appresdir=/usr/share/X11/app-defaults, and it seems that
> Debian (https://packages.debian.org/jessie/groff) passes
> --with-appresdir=/etc/X11/app-defaults to conf
Hi Ralph,
On Sun, Sep 28 2014 at 07:33:03 PM, Ralph Corderoy
wrote:
> Hi Bertrand,
>
>> Massaged path:
>> /usr/etc/X11/%L/%T/%N%C%S:
>> /usr/etc/X11/%l/%T/%N%C%S:
>> /usr/etc/X11/%T/%N%C%S:
>> /usr/etc/X11/%L/%T/%N%S:
>> /usr/etc/X11/%l/%T/%N%S:
>> /usr/etc/X11/%T/%N%S:
>
Hi Bertrand,
> Massaged path:
> /usr/etc/X11/%L/%T/%N%C%S:
> /usr/etc/X11/%l/%T/%N%C%S:
> /usr/etc/X11/%T/%N%C%S:
> /usr/etc/X11/%L/%T/%N%S:
> /usr/etc/X11/%l/%T/%N%S:
> /usr/etc/X11/%T/%N%S:
> /usr/share/X11/%L/%T/%N%C%S:
> /usr/share/X11/%l/%T/%N%C%S:
> /usr/s
Hi Ralph and Werner,
On Thu, Sep 25 2014 at 01:10:35 PM, Ralph Corderoy
wrote:
> Hi Werner,
>
>> Contrary to many other packages, a `/usr/local/X11' hierarchy normally
>> doesn't exist, and only the `/usr/X11' tree gets checked for
>> configuration files. Maybe this has changed recently, but I
Werner,
Thank you for the corrections.
If the concept of the daily snapshot is to be discontinued, the
remaining references to it ought to be removed from the documentation.
src/roff/groff/groff.man:
The most recent released version of
.I groff
is available at the
.UR http:
>> A regular, nightly?, tarball produced from git with `make
>> distcheck' would package up a ./configure so that you could use it
>> and not git and need less installed/downloaded. But I don't know
>> if one exists, or if anyone has the time to set it up as a
>> contribution.
>
> This existed un
On 9/25/14, Ralph Corderoy wrote:
> Hi Blake,
>
>> I always use the latest git version, and not any official release,
>> because it often contains corrections that are important to me.
>
> Congratulations, you're a "developer" and have to suffer all their
> tribulations. :-) A regular, nightly?,
Ulrich,
On Fri, Sep 26 2014 at 08:35:23 PM, Ulrich Lauther
wrote:
> yes, with your defs.patch applied (and the other patched stuff removed) it
> works:
>
> groff -v
>
> now gives:
>
> GNU groff version 1.22.2
> Copyright (C) 2013 Free Software Foundation, Inc.
> [disclaimer stuff]
>
> called s
Ulrich,
On Fri, Sep 26 2014 at 12:15:22 PM, Ulrich Lauther
wrote:
> On Fri, Sep 26, 2014 at 10:52:49AM +0200, Bertrand Garrigues wrote:
>> Calling 'make clean' or 'make distclean' fixed your problem. The error
>> message you got (missing file in site-font) is normal and comes from the
>> additio
On Fri, Sep 26, 2014 at 10:52:49AM +0200, Bertrand Garrigues wrote:
> Hi Ulrich,
>
> > This may be a fault on my side,
>
> No, you found a bug ...
>
> > not to use "make clean" after changing the prefix; or missing
> > dependencies?
>
> The groff binary is not rebuilt, because defs.h was not r
On Fri, Sep 26, 2014 at 10:52:49AM +0200, Bertrand Garrigues wrote:
> Hi Ulrich,
>
>
> No, you found a bug ...
>
> > not to use "make clean" after changing the prefix; or missing
> > dependencies?
>
> The groff binary is not rebuilt, because defs.h was not regenerated, and
> thus defs.h still h
Hi Ulrich,
On Thu, Sep 25 2014 at 04:32:08 PM, Ulrich Lauther
wrote:
> I made some research and found:
>
> 1.
> with
> ./configure; make
> ./configure --prefix=/home/privat/groff_test; make; make install
> groff_test/bin/groff -v
if you change frequently your configurat
On Thu, Sep 25, 2014 at 01:13:19AM +0200, Bertrand Garrigues wrote:
> Hi Ulrich,
> Hm ... I see no obvious mistake in your commands, and could not
> reproduce the problem. I have no idea of what's going on. Could you
> please apply the attached patch to trace the error we have when
> attempting to
> Ah, I've seen them under /usr/local in the past. There's various
> environment variables that can be set up to say where to look, e.g.
>
> $ XFILESEARCHPATH=/foo/%N:/bar/%N strace appres Werner 2>&1 \
> | grep Werner
This is clever :-)
> So if it's reasonable to assume a user knows
Hi Werner,
> Contrary to many other packages, a `/usr/local/X11' hierarchy normally
> doesn't exist, and only the `/usr/X11' tree gets checked for
> configuration files. Maybe this has changed recently, but I doubt it.
Ah, I've seen them under /usr/local in the past. There's various
environment
>> I always use the latest git version, and not any official release,
>> because it often contains corrections that are important to me.
>
> Congratulations, you're a "developer" and have to suffer all their
> tribulations. :-)
Yeah :-)
> A regular, nightly?, tarball produced from git with `mak
>> However, groff's original build system inconditionally installs
>> GXditview and GXditview-color in /usr/X11/lib/X11/app-defaults
>> (appresdir), no matter what prefix you put
>
> Bug! IMVHO, that is.
No, it isn't. In the old build system, the very last messages of the
`configure' script an
>>> - it prefers /usr/local/bin/gsed over /usr/bin/sed
>>>
>>> - it prefers /usr/local/bin/bison over /usr/bin/yacc
>>>
>>> Prefering the GNU versions over the native POSIX versions is bad
>>> because it causes needless build dependencies.
Mhmm. I don't find Ingo's arguments really convincing
Hi Blake,
> I always use the latest git version, and not any official release,
> because it often contains corrections that are important to me.
Congratulations, you're a "developer" and have to suffer all their
tribulations. :-) A regular, nightly?, tarball produced from git with
`make distche
Hi Bertrand,
> However, groff's original build system inconditionally installs
> GXditview and GXditview-color in /usr/X11/lib/X11/app-defaults
> (appresdir), no matter what prefix you put
Bug! IMVHO, that is.
> and I sticked to this behaviour.
Seems an opportunity to fix it.
Cheers, Ralph.
Hi Ulrich,
On Wed, Sep 24 2014 at 10:52:39 PM, Ulrich Lauther
wrote:
> I did the bootstrapping as described and then 'make dist' to generate a
> groff-1.22.2.tar.gz.
> I expanded this file at some other place, went into the new groff-1.22.2
> directory and typed
> ./configure --prefix=
Hi Ralph,
On Wed, Sep 24 2014 at 09:31:00 AM, Ralph Corderoy
wrote:
> Hi Bertrand,
>
>> 'make distcheck' will attempt to make a tarball, untar it, build it
>> (in out-of-source tree style), clean it, check it, install it and
>> uninstall it.
>>
>> You can use DESTDIR to make the install/uninsta
On Wed, Sep 24, 2014 at 12:13 PM, Werner LEMBERG wrote:
>
> > 2. users who build groff from source
>
> This is, they are using officially distributed `.tar.gz' archives for
> compilation and installation (snapshots tarballs of the git repository
> don't belong to this type).
>
Actually, I belon
On Mon, Sep 22, 2014 at 01:17:39AM +0200, Bernd Warken wrote:
> I would improve your install commands a bit into:
>
> test -d old && rm -rf old
> test -d groff && mv groff old
> git clone git://git.savannah.gnu.org/groff.git
> cd groff
> git checkout automake2
> ./bootstrap
> mkdir build
> cd buil
Hi Ralph,
Ralph Corderoy wrote on Tue, Sep 23, 2014 at 11:17:28AM +0100:
> Ingo Schwarze wrote:
>> - it prefers /usr/local/bin/gsed over /usr/bin/sed
>>
>> - it prefers /usr/local/bin/bison over /usr/bin/yacc
>>
>> Prefering the GNU versions over the native POSIX versions is bad
>> because it
Hi Werner,
> > 2. users who build groff from source
>
> This is, they are using officially distributed `.tar.gz' archives for
> compilation and installation (snapshots tarballs of the git repository
> don't belong to this type).
tarballs with configure include official releases; are there any
Hi Blake,
Blake McBride wrote on Wed, Sep 24, 2014 at 12:01:15PM -0500:
> Perhaps I am confused. Let's group users into three categories:
>
> 1. users who create documents with an already built groff
>
> 2. users who build groff from source
>
> 3. users who modify or enhance groff source c
> 2. users who build groff from source
This is, they are using officially distributed `.tar.gz' archives for
compilation and installation (snapshots tarballs of the git repository
don't belong to this type).
> 3. users who modify or enhance groff source code - groff developers
Such people com
Dear Werner,
Perhaps I am confused. Let's group users into three categories:
1. users who create documents with an already built groff
2. users who build groff from source
3. users who modify or enhance groff source code - groff developers
The type of user I am referring to is number 2.
A
> Making it more dependent on versions of other software that are
> _currently_ available on the Internet means that older copies of
> groff will no longer build when those other repositories have moved,
> are no longer available, or old versions of those libraries are not
> where expected.
How o
On Wed, Sep 24, 2014 at 10:23 AM, Blake McBride wrote:
> On Wed, Sep 24, 2014 at 12:09 AM, Werner LEMBERG wrote:
>
>>
>> > IMO, if the new make system requires a download of something that is
>> > already built and installed on my machine, then the new make system
>> > is significantly worse tha
On Wed, Sep 24, 2014 at 12:09 AM, Werner LEMBERG wrote:
>
> > IMO, if the new make system requires a download of something that is
> > already built and installed on my machine, then the new make system
> > is significantly worse than using the standard ./configure.
>
> What Bertrand is working o
Hi Bertrand,
> 'make distcheck' will attempt to make a tarball, untar it, build it
> (in out-of-source tree style), clean it, check it, install it and
> uninstall it.
>
> You can use DESTDIR to make the install/uninstall in an ordinary
> directory, e.g.:
> mkdir ~/tmp
> make distcheck DESTDIR
> IMO, if the new make system requires a download of something that is
> already built and installed on my machine, then the new make system
> is significantly worse than using the standard ./configure.
What Bertrand is working on affects the bootstrapping process, this
is, building everything fr
> Thanks for the response. IMO, if the new make system requires a download
> of something that is already built and installed on my machine, then the
> new make system is significantly worse than using the standard
> ./configure.
`Built and installed'? Then you are talking about something
diffe
>> I am using 64 bit Linux Mint 16. I can build groff just fine.
>> When I try the new build system as shown below, bootstrap starts
>> downloading gnulib. It shouldn't need it. I already have what
>> groff needs to build.
>
> Well, that's how gnulib works when it is integrated. You download
Dear Bertrand,
I see. Thanks for the explanation. I hope the ./configure method
continues to work as it has.
Thanks.
Blake
On Tue, Sep 23, 2014 at 5:23 PM, Bertrand Garrigues <
bertrand.garrig...@laposte.net> wrote:
> Blake,
>
> On Tue, Sep 23 2014 at 11:10:59 PM, Blake McBride
> wrote:
> >
Blake,
On Tue, Sep 23 2014 at 11:10:59 PM, Blake McBride wrote:
> Thanks for the response. IMO, if the new make system requires a
> download of something that is already built and installed on my
> machine,
I understand that you find annoying to download about 60 Mo when only a
small part will
Thanks for the response. IMO, if the new make system requires a download
of something that is already built and installed on my machine, then the
new make system is significantly worse than using the standard ./configure.
Thanks.
Blake
On Tue, Sep 23, 2014 at 3:42 PM, Bertrand Garrigues <
bert
Hello Blake,
On Tue, Sep 23 2014 at 09:04:33 PM, Blake McBride wrote:
> I am using 64 bit Linux Mint 16. I can build groff just fine. When I
> try the new build system as shown below, bootstrap starts downloading
> gnulib. It shouldn't need it. I already have what groff needs to
> build.
Wel
Hi Bernd,
On Tue, Sep 23 2014 at 03:35:39 PM, "Bernd Warken"
wrote:
>> Von: "Bertrand Garrigues"
>>
> With your runtests.sh, `make check' runs without errors.
OK thanks, patch commited.
>> On which environment are you working, perhaps a Debian-based distro with
>> dash as the default shell ?
Greetings,
I am using 64 bit Linux Mint 16. I can build groff just fine. When I try
the new build system as shown below, bootstrap starts downloading gnulib.
It shouldn't need it. I already have what groff needs to build.
Thanks.
Blake McBride
On Sun, Sep 21, 2014 at 2:14 PM, Bertrand Garri
> Von: "Bertrand Garrigues"
>
With your runtests.sh, `make check' runs without errors.
> On which environment are you working, perhaps a Debian-based distro with
> dash as the default shell ? It seems that the file
> contrib/gdiffmk/tests/runtests.sh has a bashism. You should have the same
> pro
Hi Ingo,
> - it prefers /usr/local/bin/gsed over /usr/bin/sed
>
> - it prefers /usr/local/bin/bison over /usr/bin/yacc
>
> Prefering the GNU versions over the native POSIX versions is bad
> because it causes needless build dependencies.
If both are available, and the code that uses them is co
Hi Ingo,
On Mon, Sep 22 2014 at 10:38:40 PM, Ingo Schwarze wrote:
> You might also wish to add a sentence like the following to
> INSTALL.REPO, right after "1. Initial build", before "First invoke
> the bootstrap script:"
>
> On operating systems supporting concurrent installation of multiple
>
Hi Bernd,
On Mon, Sep 22 2014 at 08:52:55 PM, "Bernd Warken"
wrote:
> ### ./test-suite.log:
>
> FAIL: contrib/gdiffmk/tests/gdiffmk_tests.sh
>
> /opt/development/groff/git/automake/patched/build/../contrib/gdiffmk/tests/runtests.sh:
> 50:
> /opt/development/groff/git/automake/patched/build/../co
> So this code in ./bootstrap is suboptimal:
>
> check_exists() {
> ($1 --version /dev/null 2>&1
>
> That deliberately hides the error message from the user and displays
> a bogus message instead, so you might wish to refrain from hiding
> stderr.
... given that `bootstrap' is a ready-to-
Hi Ulrich,
On Mon, Sep 22 2014 at 05:09:31 PM, Ulrich Lauther
wrote:
> To make this work on my ubuntu 12.04 LTS „Precise Pangolin“ system I
> had to apt-get install autoconf automake libtool texinfo bison flex
>
> and then to install automake 1.12.2 from source, as the version 1.11.3
> that came
Hi Bertrand,
Bertrand Garrigues wrote on Sun, Sep 21, 2014 at 09:14:27PM +0200:
> With commit a88127a4fecb307f26f2e217213d4a90e300d220 the automake2
> branch is now ready for more testing from other members of the list.
Here are some experiences and suggestions:
$ ./bootstrap 2>&1
./bootst
> Von: "Bertrand Garrigues"
> > 1) make check
> - Could you please send me the content of build/contrib/gdiffmk/tests ?
See the added archive test.tgz.
#
> - What happens if you call manually gdiffmk_tests.sh ? For example like
> this:
$ abs_top_builddir=/opt/development/groff/git/auto
On Mon, Sep 22, 2014 at 01:17:39AM +0200, Bernd Warken wrote:
>
> I would improve your install commands a bit into:
>
> test -d old && rm -rf old
> test -d groff && mv groff old
> git clone git://git.savannah.gnu.org/groff.git
> cd groff
> git checkout automake2
> ./bootstrap
> mkdir build
> cd
Hello Bernd,
Thanks for testing!
On Mon, Sep 22 2014 at 01:23:56 AM, "Bernd Warken"
wrote:
>> Von: "Bertrand Garrigues"
>> Then you can check in the TESTS file for the other targets. Please note
>> that compared to the current build system:
>> - There are 2 new targets, 'make check' and 'ma
> Von: "Bertrand Garrigues"
> Then you can check in the TESTS file for the other targets. Please note
> that compared to the current build system:
> - There are 2 new targets, 'make check' and 'make distcheck'
> - Parallel build is supported.
With both checks I got an error:
1) make che
> Von: "Bertrand Garrigues"
>
> With commit a88127a4fecb307f26f2e217213d4a90e300d220 the automake2
> branch is now ready for more testing from other members of the list.
>
> git clone git://git.savannah.gnu.org/groff.git
> git checkout automake2
> ./bootstrap
> mkdir build
> cd build
> ../config
Hello Werner and all the list,
On Mon, Sep 08 2014 at 08:11:04 AM, Werner LEMBERG wrote:
>> I've just pushed a new branch 'automake2' (branched from master at
>> commit 985b1eacaf24981f29bb4a5d53b8961dbafcdfef, about a month ago)
>> where I split my original work into smaller commits. It's not co
> I've just pushed a new branch 'automake2' (branched from master at
> commit 985b1eacaf24981f29bb4a5d53b8961dbafcdfef, about a month ago)
> where I split my original work into smaller commits. It's not completely
> finished, ...
Thanks a lot! It will take some time until I've walked over it, bu
Hello everyone,
On Tue, Aug 12 2014 at 08:56:45 AM, Werner LEMBERG wrote:
> Folks,
> before switching `officially' to the new automake branch, I suggest
> that we do another groff release, based on the current `master'
> branch. I hope I will have some time in September for doing that.
I've jus
Folks,
before switching `officially' to the new automake branch, I suggest
that we do another groff release, based on the current `master'
branch. I hope I will have some time in September for doing that.
Werner
91 matches
Mail list logo
