[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gneuralnetwork] Adding a build target?
From: |
Mohammad Akhlaghi |
Subject: |
Re: [Gneuralnetwork] Adding a build target? |
Date: |
Mon, 17 Oct 2016 22:35:54 +0200 |
Hi Ray,
On October 17, 2016 8:27:54 PM CEST, Ray Dillinger <address@hidden> wrote:
>I have written, tested, and debugged a parser and writeback utility for
>(the basic part of) the new network representation. I would like to
>make a second build target now for a version of the program that uses
>the new representation, in order to facilitate testing and further
>development, because that would greatly simplify and disambiguate how
>and where to add the new code to the project.
>
>I've been pulling routines out into a separate project to write and
>test
>code then sticking the routines back into the files to check it in, but
>this does not create a configuration where people can run and test the
>new code without pulling it out and assembling it into an independent
>project themselves, and that's crazy. It's time for that to stop.
>
>But I've only the most basic acquaintance with automake, and the
>makefiles it generates appear to me to be ridiculously complex and
>fragile piles of gibberish that depend on way too many moving parts and
>additional code to be robust or understandable. Normally, I would
>simply add a file with a second 'main' routine, and a one-line addition
>to the makefile to add a second build target. But just figuring out
>HOW
>to get automake to do this looks like a project in itself. I could
>splice it in as something different that the main executable does if
>tickled with the right command line arguments, but is that what people
>want?
>
>More to the point do we really need this 800-pound gorilla in our build
>process? Is it worth my time to climb that hill and figure out how to
>get automake to cooperate and configure what would normally be a
>one-line change??
I had exactly the same problem in the design of (GNU Astronomy Utilities,
Gnuastro).
Unfortunately the Autotoold manuals are also not written for a beginner, so
understanding how Autoconf, Automake and Libtool (if you plan to have
libraries) work can be very frustraiting at the start. I have experienced it
and know exactly how you feel.
But as the project gets larger you will start to appreciate all the energy you
put: things become so easy. In particular, note that the Autotools (Autoconf,
automake, and Libtool) are not just for building, they are also for configuring
(diagnosing the system), testing, and installing, and even distributing in the
most general cases to give you portability. For example as a developer, I love
"make distcheck": it builds the tarball, then.configures, builds, and tests in
the most general build scenario and if you have designed good tests (for "make
check") it will also find possible bugs for you.
Portability is the main focus of the Autotools. On your operating system, your
way of working is fine, but try modifying your work to other systems (for your
users) and I can assure you that you will end up building a much more ugly and
oversized Makefile than what the Autotools build.
Because it is so intertwined with Autoconf (which builds the configure script),
you gain so much information about the host's system that you can prepare for
any scenario for the build, tests, and installation (making life easuer for
your users). The Automake source (Makefile.am) is also much more cleaner than a
raw Makefile, for example this is the Makefile.am for NoiseChisel (one of the
programs in Gnuastro):
http://git.savannah.gnu.org/cgit/gnuastro.git/tree/bin/noisechisel/Makefile.am
Ofcourse this isn't the main Makefile.am, but one part of it (Gnuastro contains
multiple programs and a library).
Sorry for this long mail, but as someone who experienced exactly the same
frustration that you are experiencing, I feel so happy that I moved to
Autotools. It really makes my work now (debugging and extending Gnuastro) so
much easier. It is truely a great feeling to see Gnuastro build, tested, and
installed, on systems I have never worked on.
I should say that GNU Portability Library (Gnulib) is also extremely useful for
portability and beautifully blends in with your configure.ac and Makefile.am.
So I suggest you add that too. I have commented Gnuastro's configure.ac and
Makefile.am files heavily, they might be good examples.
I would be happy to help as much as I can in the Autotools integration. I
remember that this section (link below) of the Automake manual was the best and
got me started after a few days of frustration
https://www.gnu.org/software/automake/manual/html_node/Hello-World.html
Cheers,
Mohammad