https://review.openocd.org/c/openocd/+/8600
If you check out OpenOCD before that commit
Not sure I'm up for debugging your source tree, but to take a first
look, can you tell me what command(s) to run to get this checkout
please? I have no idea, sorry.
It didn't happen always
That's
> [...]
> Looking again at your message from last November (sorry)
>https://lists.gnu.org/archive/html/automake/2024-11/msg0.html
> I am puzzled as to what's going on.
> Maybe you can provide a runnable example of the problem?
First of all, thanks for your interest in getting to the bottom
Hi,
Subject: "make dist" bug with "EXTRA_DIST += dirname" and built-in rule for
"dirname.c"
Looking again at your message from last November (sorry)
https://lists.gnu.org/archive/html/automake/2024-11/msg0.html
I am puzzled as to what's going o
Hi - thanks for the report.
$(ANGIE_FILES) refers to source subdirectory
"src/jtag/drivers/angie/", but next to it there is a source file
called "src/jtag/drivers/angie.c".
I don't think Automake currently tries to consider the values of
EXTRA_DIST, just copies them. So it's probably
Hi all:
I have hit an interesting bug in Automake. It has taken me a few hours of
learning and experimentation to track it down.
The OpenOCD project uses the Autotools and everything seems fine: bootstrap, ./configure,
"make install", etc. work fine. Only make "make dist"
nly this, but Y's configure script needs to actually
run and its Makefiles need to be generated unconditionally. (The basic
_issue_ is what you've already tripped over: Automake needs to know
_statically_ all of the files included in package X. But many other
things besides "make dis
eds to actually
run and its Makefiles need to be generated unconditionally. (The basic
_issue_ is what you've already tripped over: Automake needs to know
_statically_ all of the files included in package X. But many other
things besides "make dist" depend on this.)
Instead, I s
is often installed as an external or system library, so X/configure
calls AC_CONFIG_SUBDIRS([Y]) in some cases, not always.
On the other hand, I want "make dist" to include "Y" subdirectory as
a directory ready to call "configure", if a user wants to do it.
How can
same error you
> reported (because the commit IDs mentioned in .git-log-fix are not
> available).
After a little more investigation, a --single-branch clone indeed works fine.
I was confused by two unrelated bugs, which happen regardless of what you clone.
1. `make dist` immediately aft
possible workaround (only if you don't care about the resulting
changelog being correct) would be to truncate .git-log-fix before
running make dist.
Cheers,
Nick
On Wed, Oct 13, 2021, at 2:11 PM, Nick Bowler wrote:
> I think this happened because your CI system has done a shallow clone.
> So the changelog generation failed because the git log is incomplete.
I did a --single-branch clone, but not a shallow one. Shouldn't the trunk be
self-contained?
zw
< I _may_ be investigating the possibility of setting up CI for automake
> so that problems like this are at least noticed in a timely fashion. But if
> the tree is broken to begin with, it's troublesome...
I think this happened because your CI system has done a shallow clone.
So the
On Wed, Oct 13, 2021, at 11:54 AM, Bob Friesenhahn wrote:
> On Wed, 13 Oct 2021, Zack Weinberg wrote:
>>
>> Looks like some kind of problem with automatic ChangeLog generation?
>
> To me this appears to be the result of skipping an important step in
> what should be the process. It seems that the
On Wed, 13 Oct 2021, Zack Weinberg wrote:
Looks like some kind of problem with automatic ChangeLog generation?
To me this appears to be the result of skipping an important step in
what should be the process. It seems that there should be a
requirement that 'make distcheck' succeed prior to
$ make V=1 dist
make dist-xz dist-gzip am__post_remove_distdir='@:'
make[1]: Entering directory '/home/zack/projects/gnu/autoconf/ci/b-automake'
make distdir-am
make[2]: Entering directory '/home/zack/projects/gnu/autoconf/ci/b-automake'
set -e; set -u; \
if te
Hi Bob,
On 9/18/19 3:22 PM, Bob Friesenhahn wrote:
> On Wed, 18 Sep 2019, Jerry Lundström wrote:
>>
>> With v1.16 this step is executed during `make dist` and using
>> `EXTRA_DIST` for that whole directory would also mean that _the built
>> library_ would be included in
On Wed, 18 Sep 2019, Jerry Lundström wrote:
With v1.16 this step is executed during `make dist` and using
`EXTRA_DIST` for that whole directory would also mean that _the built
library_ would be included in the dist.
`EXTRA_DIST` only goes so far. In my own project I use `dist-hook` to
Hi Nick,
On 9/17/19 8:25 PM, Nick Bowler wrote:
> ... I just ran this example with Automake 1.16.1 and neither ext/built.c
> nor ext/built.o are included in the distribution tar file generated by
> 'make dist'.
Exactly! Then why are they built during `make dist`?
$ make
Hi Jerry,
On 9/17/19, Jerry Lundström wrote:
> This problem seems to have been introduced in v1.16 with:
>
> - "./configure && make dist" no longer fails when a distributed file
> depends on one from BUILT_SOURCES.
>
> And what I can see in the Makefile output
On Tue, 17 Sep 2019, Jerry Lundström wrote:
I can't really see how this change got approved, isn't the point of
BUILT_SOURCES to be sources built when building!? Including them into
distributions seems wrong.
I see considerable documentation regarding BUILT_SOURCES at
"https://www.gnu.org/so
Hi,
This problem seems to have been introduced in v1.16 with:
- "./configure && make dist" no longer fails when a distributed file
depends on one from BUILT_SOURCES.
And what I can see in the Makefile output is that $(BUILT_SOURCES) has
been added to distdir.
I can't rea
'make all', 'make check' or 'make install'.
>> >
>> > So if they are going to be generated on 'make dist' as well, then the
>> > manual needs a corresponding update.
>>
>> Hi Nick,
>> Thanks for the suggestio
> >
> > So if they are going to be generated on 'make dist' as well, then the
> > manual needs a corresponding update.
>
> Hi Nick,
> Thanks for the suggestion, but I do not think it is desired. "make
> dist" is already defined as building eve
On Tue, Nov 28, 2017 at 12:01 PM, Mathieu Lirzin wrote:
> Hello Jim,
...
>>
>> Here's the patch I expect to push to master:
...
>
> OK to push.
Thanks. Pushed.
I have also removed the micro branch.
On Tue, Nov 28, 2017 at 12:45 PM, Nick Bowler wrote:
> Hi Jim,
>
> On 2017-11-28 11:21 -0800, Jim Meyering wrote:
>> Date: Thu, 20 Mar 2014 12:31:32 -0700
>> Subject: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)
>>
>> * lib/am/distd
Hi Jim,
On 2017-11-28 11:21 -0800, Jim Meyering wrote:
> Date: Thu, 20 Mar 2014 12:31:32 -0700
> Subject: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)
>
> * lib/am/distdir.am (distdir-am): New intermediate target.
> Interpose this target between $(distdir
Hello Jim,
Jim Meyering writes:
> I was dismayed to discover this patch I wrote over three years ago.
> Today I confirmed that the problem still remains by running these commands:
>
> git clone git://git.sv.gnu.org/hello.git \
> cd hello && ./bootstrap &&am
I was dismayed to discover this patch I wrote over three years ago.
Today I confirmed that the problem still remains by running these commands:
git clone git://git.sv.gnu.org/hello.git \
cd hello && ./bootstrap && ./configure && env make dist
It failed like th
rations don't change the XML at all, in which case
we just symlink the output file to point to the input file:
ln -s $xml.in $xml.out
However, I was looking into archive produced by 'make dist' the other
day and found out that the symlinks are not preserved. I've traced down
the
Young wrote:
>> On Sep 14, 2016, at 7:49 AM, Peter Rosin wrote:
>>>
>>> On 2016-09-14 11:33, Michal Privoznik wrote:
>>>>
>>>> ln -s $xml.in $xml.out
>>>>
>>>> However, I was looking into archive produced by 'make dist&#
wrote:
>>>
>>> ln -s $xml.in $xml.out
>>>
>>> However, I was looking into archive produced by 'make dist' the other
>>> day and found out that the symlinks are not preserved.
>>
>> I believe that is for the benefit of supporting unpackin
On Sep 14, 2016, at 7:49 AM, Peter Rosin wrote:
>
> On 2016-09-14 11:33, Michal Privoznik wrote:
>>
>> ln -s $xml.in $xml.out
>>
>> However, I was looking into archive produced by 'make dist' the other
>> day and found out that the symlinks are
xml.in $xml.out
>
> However, I was looking into archive produced by 'make dist' the other
> day and found out that the symlinks are not preserved. I've traced down
> the problem and found that autoconf is just hardcoding some of tar's
> options. Namely -chf. Yes, it is
id, and whether some operations change it in
expected way. Some operations don't change the XML at all, in which case
we just symlink the output file to point to the input file:
ln -s $xml.in $xml.out
However, I was looking into archive produced by 'make dist' the other
day and found
,
autoconf - 2.69, m4 - 1.4.17 and libtool - 2.4.6* packages.
The command "make clean uninstall all install" is going fine but the
command "make dist" to create the tar ball is failing on the new RHEL7.2
host with the below error:
mkdir
mkdir: cannot create directory ‘&
Hi Nick,
Ok, thanks.
I don’t know the side-effects of the COPYFILE_DISABLE flag, so I prefer not to
use it other than make dist.
Good to see the open bug report and hope it’ll be fixed sometime in the future.
In the mean time, I decided to write some code in the dist-hook to check if the
Hello,
On 2015-05-18 16:10 +0800, Bas Vodde wrote:
> On 14 May 2015, at 9:24 pm, Nick Bowler wrote:
> > But I think there is a solution: we can (ab)use the fact that 'make dist'
> > internally performs a recursive make invocation. This gives us the chance
> > to
Hi Nick,
Thanks for that.
I thought about it a bit and guess that this would *always* define the
COPYFILE_DISABLE=1. That is, not just in “make dist” but also in other targets,
correct?
I think that isn’t what I want as I don’t want to go too much against the
filesystem defaults, to avoid
Hello,
On 2015-05-10 12:57 +, Bas Vodde wrote:
> I'm trying to change my projects configure.ac so that it sets the
> COPYFILE_DISABLE=1 environment variable to influence the make dist
> target.
>
> Background: The COPYFILE_DISABLE=1 avoids having a second top-level
;(
Thanks,
Bas
> On 10 May 2015, at 4:40 pm, Gavin Smith wrote:
>
> On 10 May 2015 at 13:57, Bas Vodde wrote:
>> I'm trying to change my projects configure.ac so that it sets the
>> COPYFILE_DISABLE=1 environment variable to influence the make dist target.
>
> What ru
On 10 May 2015 at 13:57, Bas Vodde wrote:
> I'm trying to change my projects configure.ac so that it sets the
> COPYFILE_DISABLE=1 environment variable to influence the make dist target.
What running program needs to have this environment variable set in
its environment? Is it the
Hi all,
I'm trying to change my projects configure.ac so that it sets the
COPYFILE_DISABLE=1 environment variable to influence the make dist target.
Background: The COPYFILE_DISABLE=1 avoids having a second top-level
directory in your package when packaging on MacOSX.
So far, my attempt w
On 2015-04-17 00:13 +0200, Roelof Berg wrote:
[...]
> 'make dist' runs very well and its output can be built on a clean
> system, all tests pass, the tarball seems to be perfectly ok. 'make
> distcheck', however, complains about missing files:
>
> prompt$ ma
Hello,
I'm new to automake and for making my open source project 'limereg'
ready for debian I moved it to Automake. It builds mainly a library and
an executable, see:
git clone https://github.com/RoelofBerg/limereg.git
./generate-tarball-distro.sh
'make dist' runs
> -Original Message-
> From: Peter Johansson [mailto:troj...@gmail.com]
> Sent: Monday, March 09, 2015 5:40 PM
> To: Andy Falanga (afalanga); automake@gnu.org
> Subject: Re: make dist fails for EXTRA_DIST elements
>
> Hi Andy,
>
> On 03/10/2015 08:23 AM, An
path/to/header3.hpp path/to/header4.hpp
>
> This worked just fine when I did "make dist". Then, when attempting another
> build, I ran into the next scenario: headers not used on Linux but still part
> of the distribution. "No problem," I think, an
Hi Andy,
On 03/10/2015 08:23 AM, Andy Falanga (afalanga) wrote:
I try taking out the *.cpp file and try again with the same error but with the *.h. If I
take out the *.h file, all is well again and "make dist" is happy and fine.
Why is it picky with files ending with *.cpp and *.
d too. It seemed that
EXTRA_DIST was the ticket for me.
I started adding this to the Makefile.am
EXTRA_DIST = path/to/prebuild.py path/to/header1.hpp path/to/header2.hpp \
path/to/header3.hpp path/to/header4.hpp
This worked just fine when I did "make dist". Then, when att
option results
> in
> >> errors for users with 32 bit UIDs. For example, with the Open vSwitch
> >> package:
> >>
> >> 'make dist' is under the purview of automake, not autoconf. You may get
> >> a better response by involving the automak
>> errors for users with 32 bit UIDs. For example, with the Open vSwitch
>> package:
>>
>> 'make dist' is under the purview of automake, not autoconf. You may get
>> a better response by involving the automake list.
>
> Sorry - I find the line between the tw
t, it aborts with the error:
When run configure, make, make dist on Cygwin or Ubuntu 11.10, then this
error doesn't occur, indicating to me probably a failure of Lubuntu 12.10.
Note, I did *not* run autoreconf when rerunning on Cygwin.
We need more information to try to understand the issue. P
;> I'm running autoconf-2.69 and automake-1.11.6 on Lubuntu12.10 and when I
>>> run distmake for my
>>> project, it aborts with the error:
>>>
>>>> jcurl@lubuntu1210:~/winlib/build/Linux$ make dist
>>>> if test -d "winproglib-1.1.0.50.svn_20
with the error:
jcurl@lubuntu1210:~/winlib/build/Linux$ make dist
if test -d "winproglib-1.1.0.50.svn_20130427"; then find "winproglib-1.1.0.50.svn_20130427" -type d ! -perm -200
-exec chmod u+w {} ';' && rm -rf "winproglib-1.1.0.50.svn_201304
;
>> jcurl@lubuntu1210:~/winlib/build/Linux$ make dist
>> if test -d "winproglib-1.1.0.50.svn_20130427"; then find
>> "winproglib-1.1.0.50.svn_20130427" -type d ! -perm -200 -exec chmod u+w {}
>> ';' && rm -rf "winproglib-1.1.0.50.
Hello,
I'm running autoconf-2.69 and automake-1.11.6 on Lubuntu12.10 and when I
run distmake for my project, it aborts with the error:
jcurl@lubuntu1210:~/winlib/build/Linux$ make dist
if test -d "winproglib-1.1.0.50.svn_20130427"; then find "winproglib-1.1.0.50.svn_20130
On Apr 4, 2013 12:17 AM, "Russ Allbery" wrote:
>
> Daniel Pocock writes:
>
> > I use a Debian system to run autoreconf and bootstrap/make dist releases
> > for various projects (e.g. reSIProcate)
>
> > When using the release tarball on a system like Fedor
Daniel Pocock writes:
> I use a Debian system to run autoreconf and bootstrap/make dist releases
> for various projects (e.g. reSIProcate)
> When using the release tarball on a system like Fedora, issues with
> hard-coded rpath have been discovered.
> Apparently I am not
Hi,
I use a Debian system to run autoreconf and bootstrap/make dist releases
for various projects (e.g. reSIProcate)
When using the release tarball on a system like Fedora, issues with
hard-coded rpath have been discovered.
Apparently I am not alone, and this discussion has come up before in
List the .c and .h files in FOO_SOURCES.
H
for the fact that vpath and dist don't work together,
> or is that already documented somewhere?
>
I've never heard of that vpath declaration before so I couldn't say
what its even supposed to be doing.
> It doesn't quite solve the problem in my real world situation;
>
On Mon, Oct 22, 2012 at 5:10 PM, Dan Kegel wrote:
> I don't understand automake's "make dist" support, and could use a clue.
> I've boiled my problem down to the following tiny test case, in which
> "./configure; make" works, but "make dist"
On Mon, Oct 22, 2012 at 3:12 PM, Paul Davis wrote:
>> It doesn't quite solve the problem in my real world situation;
>> "make dist" didn't copy #included files, and I needed to add something like
>> EXTRA_DIST = foobar
>> to pathprob/Makefile.am.
esn't quite solve the problem in my real world situation;
"make dist" didn't copy #included files, and I needed to add something like
EXTRA_DIST = foobar
to pathprob/Makefile.am. (Maybe that's just an artifact of trying to do
"make dist" without first doing "make", though.)
Thanks,
Dan
I don't understand automake's "make dist" support, and could use a clue.
I've boiled my problem down to the following tiny test case, in which
"./configure; make" works, but "make dist" fails. It seems that
make dist is unable to follow vpath. Is th
gt;>>> into adding something like LZMA_OPT or something to "make dist-lzma".
>>>> But in my cursory googling, I could not get my grips around what
>>>> variable to use. Does anyone know?
>>>>
>>> I don't, but I have another consid
On Wednesday 14 December 2011, Peter Rosin wrote:
> Stefano Lattarini skrev 2011-12-13 18:17:
> > On Monday 12 December 2011, Peter Rosin wrote:
> >>
> >> Hoping to fix the last fail in the testsuite, I looked
> >> into adding something like LZMA_OPT or someth
On Tuesday 13 December 2011, Bob Friesenhahn wrote:
> On Tue, 13 Dec 2011, Stefano Lattarini wrote:
> >>
> > I don't, but I have another consideration: since lzma seems to be supersed
> > by xz [1][2], couldn't we simply deprecate the `dist-lzma' option in this
> > 11.1.2 version, and remove it alt
Stefano Lattarini skrev 2011-12-13 18:17:
> oOn Monday 12 December 2011, Peter Rosin wrote:
>> Hi!
>>
> Hi Peter.
>
>> I noticed that the changes to "make dist-xz" to default to -e fixed
>> the xz.test on MinGW, but that lzma.test still fails (lzma
On Tue, 13 Dec 2011, Stefano Lattarini wrote:
I don't, but I have another consideration: since lzma seems to be supersed
by xz [1][2], couldn't we simply deprecate the `dist-lzma' option in this
11.1.2 version, and remove it altogether from the next major (or even minor)
version? WDYT?
Once
oOn Monday 12 December 2011, Peter Rosin wrote:
> Hi!
>
Hi Peter.
> I noticed that the changes to "make dist-xz" to default to -e fixed
> the xz.test on MinGW, but that lzma.test still fails (lzma: (stdin): Not
> enough memory).
>
[BTW: thanks for your continuous t
Peter Rosin skrev 2011-12-12 10:14:
> Hi!
>
> I noticed that the changes to "make dist-xz" to default to -e fixed
> the xz.test on MinGW, but that lzma.test still fails (lzma: (stdin): Not
> enough memory). Hoping to fix the last fail in the testsuite, I looked
> in
Hi!
I noticed that the changes to "make dist-xz" to default to -e fixed
the xz.test on MinGW, but that lzma.test still fails (lzma: (stdin): Not
enough memory). Hoping to fix the last fail in the testsuite, I looked
into adding one something like LZMA_OPT or something to "make dis
Hi Ralf,
Scroll down for my comments.
On 11/13/10 03:00, Ralf Wildenhues wrote:
> [ Thanks Glenn for rerouting the bug report! ]
>
> Hi Behdad,
>
>> From: Behdad Esfahbod
>> Subject: On the fix for CVE-2009-4029 Automake security fix for 'make dist*'
>&g
On 04/12/2010 04:50 PM, Brian J. Murrell wrote:
> Hi All,
>
> Is there any way at all to tweak the $VERSION that used in creating the
> distdir (tarballs)? While I don't want to change the actual version of
> a given package, I do want to add an identifier to the tarball. Such an
> identifier wo
Hi All,
Is there any way at all to tweak the $VERSION that used in creating the
distdir (tarballs)? While I don't want to change the actual version of
a given package, I do want to add an identifier to the tarball. Such an
identifier would be introduced by a configure switch and thus subst'd
int
* Ralf Wildenhues wrote on Tue, Dec 08, 2009 at 11:13:45PM CET:
> For release branches older than branch-1-10, the respective fix has been
> applied to the git tree, but there are currently no plans to produce new
> official releases for them; contact us if you absolutely need to have
> such a rele
GNU Automake 1.11.1 as well as 1.10.3 fix a security-related race
condition that affects `make dist' and `make distcheck' for all packages
that use Automake. Before the fix, the `distdir' target (which is used
by both `dist' and `distcheck') would first populate a direc
On 9/28/2009 7:09 PM, John Calcote wrote:
Bruce,
On 9/28/2009 7:03 PM, David Bruce wrote:
Sorry David, then I went and got your first and last names mixed up.
Perhaps I'd better just be quiet now. ;)
Bruce,
On 9/28/2009 7:03 PM, David Bruce wrote:
Hello Ralf,
I found it! It was an utterly perversely subtle typographical error:
In my src/Makefile.am:
tuxmathserver_SOURCES = servermain.c\
server.c \
mathcards.c \
throttle.c \
Hello Ralf,
I found it! It was an utterly perversely subtle typographical error:
In my src/Makefile.am:
tuxmathserver_SOURCES = servermain.c\
server.c \
mathcards.c \
throttle.c \
. options.c
^
|
|
A
ittle modification of configure.ac or Makefile.am
files recently, so I find this problem pretty baffling.
I suspect that this is the first time that these files have been
reviewed by anyone with any serious autotools knowledge.
Thanks again,
David Bruce
Here's that Makefile.am for the font di
* David Bruce wrote on Mon, Sep 28, 2009 at 01:08:58AM CEST:
> On 9/27/09, Ralf Wildenhues wrote:
> > * David Bruce wrote on Sat, Sep 26, 2009 at 04:51:01AM CEST:
> >> My project is not creating valid tarballs with "make dist", and "make
> >>
Hello Ralf,
On 9/27/09, Ralf Wildenhues wrote:
> Hi David,
>
> * David Bruce wrote on Sat, Sep 26, 2009 at 04:51:01AM CEST:
>> My project is not creating valid tarballs with "make dist", and "make
>> distcheck" fails at the VPATH build stage.
>
>
Hi David,
* David Bruce wrote on Sat, Sep 26, 2009 at 04:51:01AM CEST:
> My project is not creating valid tarballs with "make dist", and "make
> distcheck" fails at the VPATH build stage.
Please post your Makefile.am files in toplevel and src. We might also
need to
My project is not creating valid tarballs with "make dist", and "make
distcheck" fails at the VPATH build stage.
1. My project has all the *.c source files in a src directory under
trunk. I normally always do vpath builds, and the svn src directory
contains no object fi
Hello,
* Peter Johansson wrote on Sat, Aug 15, 2009 at 10:48:44PM CEST:
> Bob Friesenhahn wrote:
> >I have not verified if referencing a file outside of the source
> >tree really works properly.
> >
> My experience is that inclusion of an external file will be ignored
> by Automake, in other words
Hi Bob and Roger,
Bob Friesenhahn wrote:
I have not verified if referencing a file outside of the source tree
really works properly.
My experience is that inclusion of an external file will be ignored by
Automake, in other words, the include statement ends up in the Makefile.
It might still
On Sat, 15 Aug 2009, Roger Leigh wrote:
I hadn't come across this before; I didn't realise it had Makefile.am
fragments as well. That's perfectly OK by me.
How does one extract these bits into a project's Makefile.am
automatically? Or is it just a matter of copying and pasting the
needed bits
nate tarballs. It's to
Good.
Additionally, VCSes don't typically store the results of "make dist",
only the source for that. Due to changing tool versions over the
This is a choice which varies by project. Some projects (like mine)
are rash and do commit generated files.
TH support
• checking for already-tagged repos
• tagging of both release and distribution branches
• customisation of both release and distribution tagging behaviour,
as well as allowing it to be skipped e.g.
make dist-git GIT_RELEASE_TAG=false
> You could consider submitting this fragment as
* Roger Leigh wrote on Sat, Aug 15, 2009 at 12:13:21PM CEST:
> Additionally, VCSes don't typically store the results of "make dist",
> only the source for that. Due to changing tool versions over the
> years, you can get in a situation where you can no longer reboot
en we are going git→git,
this makes much more sense than making a tarball and re-importing it;
not only is it more convenient, it's tied into the history of the
whole repo, which a tarball loses. This allows for easy pushing and
pulling of changesets both upstream and downstream.
Additionally,
Hello Roger,
* Roger Leigh wrote on Fri, Aug 14, 2009 at 11:40:18AM CEST:
>
> An initial implementation follows. This works, but it does need
> further refinement (error checking, for example). And probably
> review by a git expert. I'm sure other people can make it much
> nicer, but this hope
On Fri, 14 Aug 2009, Roger Leigh wrote:
ÿÿ distribute generated release tarball
However, the "distribute release tarball" step is becoming less and
less relevant with the advent of git.
The "release tarball" step is always needed since software development
is protected by copyright laws so w
On Fri, Aug 14, 2009 at 12:07:39AM +0100, Roger Leigh wrote:
> This is a rough outline of what I'd like to do (unless someone beats
> me to it!)
>
> • Add a dist-git option and Makefile target.
> This will cause $distdir to be injected into git, rather than just
> calling tar as for other git
Hello Roger,
* Roger Leigh wrote on Fri, Aug 14, 2009 at 01:07:39AM CEST:
> What can automake do?
>
> This is a rough outline of what I'd like to do (unless someone beats
> me to it!)
>
> • Add a dist-git option and Makefile target.
> This will cause $distdir to be injected into git, rather th
Hi folks,
There's no patch for this yet, I'm afraid. I just wanted to throw
out some ideas I had relating to managing releases with automake,
and integrating this with a git workflow. Sorry if it's a bit
rambling.
I've long been using automake, and I've always used
Hello Christian,
* Christian Rössel wrote on Fri, Apr 17, 2009 at 06:35:54PM CEST:
> in the following project "make" succeeds but in the result of "make
> dist" the source test/src/bar.c is missing. "make distcheck" fails.
> "make distcheck" fai
Hi,
in the following project "make" succeeds but in the result of "make
dist" the source test/src/bar.c is missing. "make distcheck" fails.
Assume following directory layout:
test/
test/cfg/
test/cfg/Makefile.am
test/cfg/configure.ac
test/cfg/src/
test/cfg/src/foo.c
Hello Michel,
* Michel Briand wrote on Tue, Feb 10, 2009 at 11:19:51AM CET:
>
> I'm working on a project that release code/library but also a large
> amount of data.
>
> I wonder if it's possible to create 2 packages with make dist. One for
> the software, one for
1 - 100 of 222 matches
Mail list logo
