On 13/03/14 11:52, Steffen Nurpmeso wrote:
> More than three years of a many-man show with autotools.
Apparently ineffectively. It took me around two weeks with the autoconf
manual, to recognize its (enormous) potential, (and about the same, to
identify automake as one autotool too far).
> In co
> Well, I will not be participating in that;
:-)
> it's a personal view, but I firmly believe that automake *creates*
> more problems than it solves
Which ones? Maybe your biased view is related to mingw?
> -- indeed, I don't even understand what problem it does solve.
Out of my head:
. It a
Hi Werner,
Werner LEMBERG wrote on Wed, Mar 12, 2014 at 10:28:43PM +0100:
> Ingo Schwarze wrote:
>> Werner Lemberg wrote:
>>> Instead, you might contribute a patch to implement a
>>> `--without-doc' configure switch that completely disables the
>>> generation of documentation files. :-)
>> Why w
hey,
Ralph Corderoy wrote:
|Hi Steffen,
|
|> Then `configure' only needs to change when something changes, like
|> adding perl(1) detection or similar.
|
|It can also change due to different versions of autoconf being used by
|developers; the same functionality represented by differing ex
Hi Steffen,
> Then `configure' only needs to change when something changes, like
> adding perl(1) detection or similar.
It can also change due to different versions of autoconf being used by
developers; the same functionality represented by differing expansions
of the macros. Alternating commit
Hello Ralph,
Ralph Corderoy wrote:
|Hi Steffen,
|
|>> It is a very good principle to put only real source files into a git
|>> repository, and no generated files. I will continue so. My
|>> successor might make a different decision, though.
|>
|> Sure, that is your decision.
|
|It's a
On 13/03/14 06:17, Werner LEMBERG wrote:
>> This was always an annoyance in CVS; with the recent migration to
>> git, now would probably be a good time to drop the generated
>> configure file from the repository.
>
> I suggest to do that as soon as someone is going to convert everything
> to autom
> This was always an annoyance in CVS; with the recent migration to
> git, now would probably be a good time to drop the generated
> configure file from the repository.
I suggest to do that as soon as someone is going to convert everything
to automake.
Werner
On 12/03/14 22:06, Ralph Corderoy wrote:
>>> It is a very good principle to put only real source files into a git
>>> repository, and no generated files. I will continue so. My
>>> successor might make a different decision, though.
>>
>> Sure, that is your decision.
>
> It's also long-standing n
>>> Instead, you might contribute a patch to implement a
>>> `--without-doc' configure switch that completely disables the
>>> generation of documentation files. :-)
>
> Really?
Yes.
> Why would somebody ever want to build a piece of software without
> the documentation belonging to it?
To be
Hi Steffen,
> > It is a very good principle to put only real source files into a git
> > repository, and no generated files. I will continue so. My
> > successor might make a different decision, though.
>
> Sure, that is your decision.
It's also long-standing normal practice. It's a real pain
On Wed, Mar 12, 2014, Ingo Schwarze wrote:
> Really? Why would somebody ever want to build a piece of software
> without the documentation belonging to it? Documentation is an
> integral part of software, and without the proper documentation,
> almost any software is next to useless.
If you alre
Hello Ingo,
Ingo Schwarze wrote:
|Hi,
|
|Steffen Nurpmeso wrote on Wed, Mar 12, 2014 at 08:59:29PM +0100:
|> Werner LEMBERG wrote:
|
|>> Instead, you might contribute a patch to implement a
|>> `--without-doc' configure switch that completely disables the
|>> generation of documentation
Hi,
Steffen Nurpmeso wrote on Wed, Mar 12, 2014 at 08:59:29PM +0100:
> Werner LEMBERG wrote:
>> Instead, you might contribute a patch to implement a
>> `--without-doc' configure switch that completely disables the
>> generation of documentation files. :-)
Really? Why would somebody ever want t
Peter Schaffter wrote:
|On Wed, Mar 12, 2014, Werner Lemberg wrote:
|>> Would it make sense to send a patch that does this if at the end of
|>> all the conditions there is still no `gnu.eps'?
|>
|> No, thanks. Instead, you might contribute a patch to implement a
|> `--without-doc' configur
Werner LEMBERG wrote:
|>|installed to build the info files, or `autoconf' to generate the
|>|configure script. People who check out from the git *must* have
|>|all
|>
|> Hah! I was really thankful that the generated `configure' became
|> part of the git(1) repo -- *thank you* for this de
On Wed, Mar 12, 2014, Werner Lemberg wrote:
> > Would it make sense to send a patch that does this if at the end of
> > all the conditions there is still no `gnu.eps'?
>
> No, thanks. Instead, you might contribute a patch to implement a
> `--without-doc' configure switch that completely disables
On Wed, Mar 12, 2014, Werner Lemberg wrote:
> It is a very good principle to put only real source files into a git
> repository, and no generated files. I will continue so. My successor
> might make a different decision, though.
I'm behind Werner on this.
> > E.g., if i would be a MOM user i su
> |installed to build the info files, or `autoconf' to generate the
> |configure script. People who check out from the git *must* have
> |all
>
> Hah! I was really thankful that the generated `configure' became
> part of the git(1) repo -- *thank you* for this decision!
Well, I consider thi
Werner LEMBERG wrote:
|> ...and no chance to take advantage of git(1) compressing it's
|> blobs, which is what i was indeed referring to? The bitmap seems
|> to be unchanged from the first check-in until today (and i can't
|> imagine that someone wants to change that one, too).
|
|It is a v
> ...and no chance to take advantage of git(1) compressing it's
> blobs, which is what i was indeed referring to? The bitmap seems
> to be unchanged from the first check-in until today (and i can't
> imagine that someone wants to change that one, too).
It is a very good principle to put only rea
Hello,
Werner LEMBERG wrote:
|> for me the dependency upon Netpbm is "annoying"; i always restart
|> failed makes to get over all related problems: like that
|> (single-threaded) compilation is just fine.
|
|With the distributed tarballs, there is *no* dependency on Netpbm!
This may be so,
> for me the dependency upon Netpbm is "annoying"; i always restart
> failed makes to get over all related problems: like that
> (single-threaded) compilation is just fine.
With the distributed tarballs, there is *no* dependency on Netpbm!
> Configuration checks for (some) Netpbm programs and av
23 matches
Mail list logo
