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'
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
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
# 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
http://sources.redhat.com/automake/automake.html#Hard_002dCoded-Install-Paths
Informative. Though I still maintain that it's a Bad Thing. Heh.
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
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
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?
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:
Can you provide a link to your project? Are you using a special VCS?
No, sorry - it is private for now.
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
> 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
> 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
> 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.
> 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 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
> 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
> 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
> 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
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
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
21 matches
Mail list logo
