gneuralnetwork
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]