> 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,
15 matches
Mail list logo
