Fwd: [ats-lang-users] ATS build system issues

[Hongwei Xi]

---------- Forwarded message ----------
From: Hongwei Xi <gmh...@gmail.com>
Date: Tue, Oct 21, 2014 at 11:56 AM
Subject: Re: [ats-lang-users] ATS build system issues
To: Barry Schwartz <chemoe...@chemoelectric.org>
Cc: Albert Graef <agg...@gmail.com>, ats-lang-users <ats-lan...@lists.sourceforge.net>

Makefile for ATS is not generated by automake.

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

On Tue, Oct 21, 2014 at 4:57 AM, Barry Schwartz <chemoe...@chemoelectric.org> wrote:

Albert Graef <agg...@gmail.com> skribis:
> Subject: [ats-lang-users] ATS build system issues
> From: Albert Graef <agg...@gmail.com>
> Date: Tue, 21 Oct 2014 10:32:54 +0200
> To: ats-lan...@lists.sourceforge.net
>
> Hi everybody,
>
> 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
> https://sourceforge.net/projects/ats2-lang, 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.
http://p.sf.net/sfu/Zoho
_______________________________________________
ats-lang-users mailing list
ats-lan...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ats-lang-users

[Hongwei Xi]

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.

On Tue, Oct 21, 2014 at 12:12 PM, Barry Schwartz <chemoe...@chemoelectric.org> wrote:

Hongwei Xi <gmh...@gmail.com> skribis:

> 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 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.

[Barry Schwartz]

Hongwei Xi <gmh...@gmail.com> skribis:

> 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.

[Hongwei Xi]

---------- Forwarded message ----------
From: Hongwei Xi <gmh...@gmail.com>
Date: Tue, Oct 21, 2014 at 1:26 PM
Subject: Re: [ats-lang-users] ATS build system issues

To: Albert Graef <agg...@gmail.com>

Good point.

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.

--

Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email:  agg...@gmail.com
WWW:    https://plus.google.com/+AlbertGraef

[Hongwei Xi]

I am looking forward to it :)

--
You received this message because you are subscribed to the Google Groups "ats-lang-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/20141021170859.GA11181%40crud.

[Barry Schwartz]

Hongwei Xi <gmh...@gmail.com> skribis:

> I am looking forward to it :)

I have played with autotools, cmake, and scons, and come out convinced
that autotools is the only way to go, of the three. It produces
packages that have uniform behavior (very important for distro
packagers), mixes well with Gnulib, and is quite flexible (at the
expense of m4 programming).

I would avoid cmake like the plague. Once taught it, with difficulty,
how to handle ocaml and was shocked what I saw in that system.
Switched that experimental project to scons ASAP.

[Raoul Duke]

> I am looking forward to it :)

yeah, i hope somebody has the time and brains to fire up something
else, like scons or cmake or shake
(http://community.haskell.org/~ndm/shake/) :-)

http://freecode.com/articles/stop-the-autoconf-insanity-why-we-need-a-new-build-system

[Raoul Duke]

and I know Barry disagrees. he has the advantage of having real
experience so i have to bow to that ;-)

[Barry Schwartz]

Raoul Duke <rao...@gmail.com> skribis:

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.

[Brandon Barker]

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.

--
You received this message because you are subscribed to the Google Groups "ats-lang-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/20141022001542.GB17019%40crud.

--
Brandon Barker
brandon...@gmail.com

[Hongwei Xi]

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:

>>1. Learn what the intent behind autotools is

>>2. Learn how the toolchain works - what generates what?

>>3. 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.

On Tue, Oct 21, 2014 at 9:53 PM, Barry Schwartz <chemoe...@chemoelectric.org> wrote:

Hongwei Xi <hw...@bu.edu> skribis:
> 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.

[Barry Schwartz]

Hongwei Xi <gmh...@gmail.com> skribis:

> The comment was made in 2006. Given it is 2014 now, the situation may have
> changed drastically.

One of the big slip-ups people make when not using Automake is poor
support for staged installs, which messes up most distro packaging
facilities. The packager ends up having to makeshift things, often
consisting of avoiding ‘make install’ entirely. Setting DESTDIR in the
make command should work. I’ve done packaging for Gentoo, Exherbo,
Debian, Ubuntu, Fedora, and long, long ago for Slackware [*]. Only the
last involved installing the package to its final location.

As a related matter, it is also necessary that the build and (staged)
install work in a sandbox.

Outside-of-source builds, and never having to edit checked-in files
for configuration, are highly desirable for
developers. Outside-of-source builds also are desirable for some
packaging situations.

Parallel builds and installs are desirable and also a good check of
the makefile’s completeness. (It can require significant makefile
trickery, however.)

I’ve seen seriously broken uninstall features, too, so IMO uninstall
should be automated as much as possible. The same goes to a much
lesser degree for make clean.

Automake also takes care of dependency tracking for C, though this can
be coded by hand as explained in the GNU Make manual or some
such. Dependency tracking for C does not matter when simply building a
package, however. (This is not true for all languages.)

In short, the build system should assume an outside-of-source parallel
build and parallel staged install, in a sandbox, with uninstall,
clean, distclean, dependency tracking if at all possible, and no doubt
other features.

Automake also has a rather good packaging testing facility that helps
make sure you do not leave stuff out of the package, and that an
outside-of-source build works. IMO it may be worth using Automake just
for that. (It doesn’t help avoid the ‘failed to commit a file’
problem, unfortunately.)

If you want to know what I hate and try to avoid, its gettextize and
GNOME’s intltoolize. :)



[*] 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. :) )

[gmhwxi]

>>[*] 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.

[gmhwxi]

Hi Barry,

I have to confess that we do have another way to build ATS
that is based on cmake:

https://github.com/githwxi/ATS-Postiats/blob/master/src/CMakeLists.txt

It is a parallel outside-of-source build. I just checked that it could still be
used build ATS without any issues.

I know that you dislike cmake. Still, I would like to get your opinion on
whether cmake can do the job under Windows.

[Barry Schwartz]

gmhwxi <gmh...@gmail.com> skribis:

I have no idea. :) Windows is different enough that nothing I say
applies to it. I’ve never built anything for a Microsoft system since
the MSDOS days except once for Cygwin.

(My objection is actually milder than I have made it seem. I am a
Pólya type [http://en.wikipedia.org/wiki/George_P%C3%B3lya]: I think
one should try to solve a problem by solving a more general problem.)

[Barry Schwartz]

I wrote:
> (My objection [to cmake] is actually milder than I have made it seem. I am a

> Pólya type [http://en.wikipedia.org/wiki/George_P%C3%B3lya]: I think
> one should try to solve a problem by solving a more general problem.)

I mean that if what you want is just to build a C program or something
like that, cmake may do the job well. So might a dozen other tools
that know C well but aren’t especially flexible.

OTOH adopting it for something as broad as KDE (which doesn’t even
have to run on Windows) had the effect of limiting what KDE-related
projects could employ.

[Barry Schwartz]

gmhwxi <gmh...@gmail.com> skribis:

> I have built this suggestion into patscc; -Wl,--warn-common
> is now passed to gcc by default.

I’d probably not do that, because it depends on the linker being GNU
ld. My autoconfs check whether the flag is accepted by the compiler,
before inserting it; and I think they insert it only when linking.

Now that I think about it, it is how I deal with Apple’s
non-traditional linker, which I think is too strict, but only because
it rejects a common idiom that I consider bad style. The flag is
unlikely to make a difference in ATS programs, but might if there is
much C code included: it warns about cases where somebody declared a
variable extern in a .h file without separately defining it in a .c
file.

The problem with Debian the Debian linker is one that makes it
ferociously more difficult to construct some dlopenable plugins: it
prunes out symbols that are not explicitly used somewhere in the
library. If you are in a hurry and care only to make it work on
Debian, you can simply set the GNU default flags explicitly, but a
similar problem probably exists on Apple or elsewhere.