e info.
> You should be using $(top_srcdir). Better even if you
> cd "$(top_srcdir)" && find . -name ...
Thanks for this!
Best,
--
Noah Slater, http://bytesexual.org/nslater
clean this up for me?
* Should I be using $(top_srcdir) in those rules or is it safe to assume that
the target is being run from the top source directory?
I realise there may not be "correct" answers to these, but was mainly look for
some idea of best practice.
Thanks,
--
Noah Sl
> I disagree. In a centralised VCS sure, you can scale to 100's of commits
> a day - but in a distributed VCS - e.g. bzr, git, hg, monotone ... you
> tend to get 100's of commits on branches, and a much smaller number of
> branch merges occuring - branch merges being the point at which code
> revie
> I think you misunderstanding me, it's the generation if the changelog
> that will take too long time.
Well, yes - what else could I have understood from:
> That not an optimal option, as it's illogical to store those files in the svn.
How long does it take to generate?
--
"Creativity can be
> That not an optimal option, as it's illogical to store those files in the svn.
Well don't store them in svn - use a bootstrap script to make them
before running the autotools.
Here is the bit from my ./bootstrap that does the magic:
get_svk_svn_directory () {
# Return the SVN repository d
> The problem I have with generating ChangeLog, is that it will be BIG,
> for example, bmpx generate at the moment ChangeLog from svn log, and
> it ends up to 2.6 MB.
The common solution is to use:
ChangeLog
ChangeLog.1.gz
ChangeLog.2.gz
> Only projects overcome with sloth do not maintain a ChangeLog.
Why do something your self when the computer can do it for you?
That's what we invented these things for, right?
> Version control systems come and go and are often not accessible to
> everyone while the tarball may continue to exi
> The reason for this is:
> ChangeLog: often mostly a duplicate of svn/cvs logs, seldom really used
I agree about ChangeLog - there is no reason to be using this any more.
> I'm looking here:
> http://sources.redhat.com/ml/automake/
You're guess is a good as mine, sorry.
--
"Creativity can be a social contribution, but only in so
far as society is free to use the results." - R. Stallman
> I see no messages in the archives for this list for the past two
> years. Is this list dead? If so, where is the appropriate place for
> receiving automake support?
This is a very low volume list - but not /that/ low volume.
You must looking in the wrong place.
Noah
--
"Creativity can be a
You can use the prefix "dist_" with a variable to have it distributed
in the tarball.
dist_SRC = foo
Also, if you are making the bin files at distribution time you should
replace CLEANFILES with MAINTAINERCLEANFILES and change BIN to
dist_BIN.
Additionally, I am unsure why the ".txt.bin" rul
Can you provide a link to your project? Are you using a special VCS?
No, sorry - it is private for now.
I do something similar for building an nsis-based win32 installer:
I will check this out tomorrow. Thanks.
Also, you may wish to reconsider whether it is wise to include a
debian target/directory directly, or whether you might follow the
usual convention for delivering debian source packages:
Hello,
I am developing a package with Automake that needs to have a custom
dist taget for making debian packages in addition to the usual
tarballs etc.
I have created a dist-deb that works perfectly but I am unable to find
any way of including this into the distcheck target.
Is this possible?
Hello,
Why does Automake not generate text output (using makeinfo) rules for
documentation?
I would like to provide the "make txt" and "make install-txt" targets
for my documentation but am unwilling to hack around trying to kludge
this feature on.
Is there any reason this functionality is miss
Sounds like my best solution would be to use the "sysconf_DATA" option.
Any ideas how to take 'sysconfdir' and somehow import it into my program
so it knows where the default configuration files are?
Well, I use Python and I have a file called 'lib/foo/__init__.py.in'
that is has the following l
http://sources.redhat.com/automake/automake.html#Hard_002dCoded-Install-Paths
Informative. Though I still maintain that it's a Bad Thing. Heh.
# Makefile.am for installing configuration data
etcdir=/etc/lx2005
etc_DATA = serlog.conf
This is seriously broken. What if my /etc directory is read-only, for example.
This breaks any hope of getting a VPATH build.
When I run 'make distcheck' it fails as it cannot install the files
Hello,
I notice that the [EMAIL PROTECTED] and [EMAIL PROTECTED] both have PACKAGE and
VERSION information properly filled in for my package. On the other
hand, the pot file generated just has the text place-holders.
Why does Automake NOT fill in these place-holders in the pot file?
Thanks,
No
Hello,
I notice that the Makefile generated by Automake refuses to call
install-info if the --version output indicates it is the Debian
version.
Why is this? I would like install-info to be called on Debian and Ubuntu.
Thanks,
Noah
--
"Creativity can be a social contribution, but only in so
f
Hey,
Do you know about VPATH builds?
Yes, what an idiot I was not to consider this.
You also made a typo, (s/CLEAN_FILES/CLEANFILES/) but make distcheck
would have revealed this problem too.
Ah yes, it was doing - I wonder how that slipped in there.
I also recommend passing the
`foreign'
21 matches
Mail list logo
