For now, I have added the following line to tell the user to ignore
any error messages by automake:
echo "autogen.sh: please ignore any error messages by automake."On Tue, Oct 21, 2014 at 11:31 AM, Hongwei Xi gmh...@gmail.com wrote:
If I remove it, I get the following output:
configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found.
configure.ac: You should verify that configure.ac invokes
AM_INIT_AUTOMAKE,
configure.ac: that aclocal.m4 is present in the top-level directory,
configure.ac: and that aclocal.m4 was recently regenerated (using
aclocal).
automake: no `Makefile.am’ found for any configure output
I’m currently reviewing a pull request to add an ATS interface to the
Pure
programming language. While giving ATS a try, I noticed two minor issues
with the build system. I can’t find a way to file a bug report at ats2-lang download | SourceForge.net, so I’m posting this here:
There’s no make uninstall target. Makes it hard to test install the
package. Fortunately, it’s also available in the AUR. But there’s no
ats2-git package there, so in order to test drive the git sources the
make
uninstall target would definitely be convenient.
Using the git version, running autogen.sh I’m getting this:
$ ./autogen.sh
configure.ac:70: installing ‘./compile’
configure.ac:68: installing ‘./install-sh’
configure.ac:68: installing ‘./missing’
automake: error: no ‘Makefile.am’ found for any configure output
The missing files are generated all right, but the error message
indicates
that there’s something wrong with your setup. There’s no Makefile.am
anywhere, so automake is bound to complain. While it’s harmless, it may
look troublesome to users. Maybe the missing files can be created in a
different way, or you might just redirect automake’s stderr in order to
suppress the message.
Yeah, that’s an actual bug, because there is no Makefile.am. The
correct fix is to remove AM_INIT_AUTOMAKE from the configure.ac.
(I had totally forgotten about that bug because there is a workaround
coded in my Gentoo eclass for building ATS2; the script removes the
offending line and then autoreconfs.)
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device. Best Open Source Mac Front-Ends 2023
Wow. I don’t want to derail this topic further but here goes - kompostilo
is now the 2nd typesetting system I’ve heard of that is written in Ocaml.
The first is http://patoline.org, which I believe I mentioned on this list
a few months ago.On Tue, Oct 21, 2014 at 8:15 PM, Barry Schwartz < chemoe...@chemoelectric.org> wrote:
Cmake has too much C/C++/etc functionality hardcoded into it. I
remember one KDE project that used ocaml being caught off-guard after
the switch to cmake. I think they ended up removing the ocaml
code. This is like using nails instead of screws because the tool you
have is a hammer.
Scons does complicated things excellently, easily, and quickly, and
makes Make’s dependency handling seem like garbage. Ocaml’s fancy
dependencies were a breeze (as long as I used timestamps rather than
diffs to detect changes). However it also makes very simple things so
difficult I never figured them out. I used it for kompostilo
typesetter, which was an experimental derivative of Ant (the
typesetting program) that I used to make some e-books.
Another reason is I hate to RTFM and with autotooled packages I almost
never have to RTFM.
[*] Also watch out for the linker on Debian/Ubuntu; the settings are
not GNU default and can cause mysterious problems. Try setting
-Wl,–warn-common on your gcc/patscc command line to catch potential
problems. This may help also to keep your stuff working on MacOS,
which has a ‘non-traditional’ linker. (I learnt C from K&R 1st ed and
so expect traditional everything. )
Thanks.
I have built this suggestion into patscc; -Wl,–warn-common
is now passed to gcc by default.
I have just added a couple lines in Makefile to remove most of the
generated .o files.On Tue, Oct 21, 2014 at 12:59 PM, Albert Graef agg...@gmail.com wrote:
On Tue, Oct 21, 2014 at 6:39 PM, Hongwei Xi gmh...@gmail.com wrote:
By the way, ‘make uninstall’ is now supported.
Thanks.
‘make clean’ doesn’t seem to do much either:
$ make clean
make: Nothing to be done for ‘clean’.
And after that all the .o files are still there. I need to run ‘make
cleanall’ to get rid of those, but that will also remove other important
stuff so that I need to run configure again.
and I know Barry disagrees. he has the advantage of having real
experience so i have to bow to that ;-)On Tue, Oct 21, 2014 at 4:48 PM, Raoul Duke rao...@gmail.com wrote:
To be honest, I don’t even remember who wrote the configure.ac
For now, I would just keep it. The “please ignore …” stuff isn’t a
pretty
solution but it is cheap.
By the way, ‘make uninstall’ is now supported.
Perhaps someday I or someone else could write more complete
autotooling, if there is no personal stake in the current system.
That way it would be easy to make a shared and/or static library of
atslib, too; it ought to be available as a shared library so it can be
dlopened on systems like GNU and Solaris that support that.
configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found.
configure.ac: You should verify that configure.ac invokes
AM_INIT_AUTOMAKE,
configure.ac: that aclocal.m4 is present in the top-level directory,
configure.ac: and that aclocal.m4 was recently regenerated (using
aclocal).
automake: no `Makefile.am’ found for any configure output
I would try removing automake from the autogen.sh script, too.
(Meanwhile I discovered my Gentoo stuff isn’t doing the autoconf,
after all. It’s buggy.)
I always use Automake when using Autoconf, but it is a lot of
hacking to use both Automake and GNU Make features together. Much of
the stuff in my ‘sortsmill’ repositories at Bitbucket consists of such
ugly hacking. Hopefully Automake 2 will be more copacetic.
The comment was made in 2006. Given it is 2014 now, the situation may have
changed drastically.On Tue, Oct 21, 2014 at 10:32 PM, Hongwei Xi gmh...@gmail.com wrote:
I saw this on-line. The point made by the author resonates with me:
Missing features in scons
I’ve been working with autotools for about 4 years now - the first 3
years I didn’t know what I was doing, and just tried to hack my way
through when there was a problem. This last year, I decided to really
understand it. It’s been painful, but worth the effort. The really sad
part is that it didn’t have to be that painful. If there were a really
good tutorial on not just the mechanics of autotools, but on the
underlying motivation for it, and if all of this documentation were
gathered into a single place, it would have been almost painless. >>Here’s
the basis for understanding autotools, step by step:
Learn what the intent behind autotools is
Learn how the toolchain works - what generates what?
Learn the underlying language (m4).
Now you have a half a chance at understanding what it does. Quit trying
to think you can hack your way through autotools input files >>without
understanding what they are for and how they work.
By the way, I think that many complaints about autotools are due
to autotools not being used properly or even correctly, just like the
case we saw here.
The complaint that it is Unix-centric is valid, but my attitude
towards other development platforms is that I do not have them, I
cannot get them, and I am not (and due to disability never will be)
paid to deal with them. The platform itself belongs to someone else
who will not share it, and my life-hours disappear before my eyes when
I try to wrestle past that boundary. Which, believe me, I have tried
to do. And other packaging schemes seldom work as well for me as their
proponents claim; perhaps partly because usually I write a Gentoo
ebuild, which easily defies the writer’s assumptions as to what a
build system should do.
BTW does anyone have ATS running on a BSD with Boehm GC? I’ve had
terrible trouble with BSDs and Guile 2, which also uses Boehm GC; I
managed to get a static build of Guile on NetBSD, and that’s it.
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device. Best Open Source Mac Front-Ends 2023
But there’s no
