Re: Prayertime autotools (again)

[Thamer Mahmoud <neokuwait at hotmail dot com>]

Err... I accidently hit the Send button. Here the complete message.

Samy Al Bahra writes:
 > On Tue, 23 Dec 2003 12:09:43 -0800 (PST)
 > Nadim Shaikli <shaikli at yahoo dot com> wrote:
 > 
 > > --- Thamer Mahmoud wrote:
 > > > 
 > > > Modified Files:
 > > > 	Makefile.cvs configure.in 
 > > > Added Files:
 > > > 	Makefile.am Makefile.in.old configure.in.old 
 > > > Removed Files:
 > > > 	Makefile.in 
 > > > 
 > > > Log Message:
 > > > This make process uses automake. less error prone - more
 > > > features..etc.
 > 
 > > Thamer, the entire process now again doesn't work for me (on
 > > solaris) and we are pretty much back to where we were prior to
 > > the most recent minimalistic change (which I very much liked btw
 > > since this lib/app is small itself).  The amount of files and
 > > links created now just seems overwhelming and unnecessary.


Sorry for the late reply. For some reason, I didn't receive Nadim's
message, so I'm replying here instead to both messages. Nadim, just
for the record, would you please state which parts didn't work for
you? Error messages, if any?


 > > Could we do this ?  Go back to the previous minimalistic
 > > autotools process and address any concerns you might have
 > > (ie. address those 'error prone' issues) as well as add whatever
 > > required features (not sure what those might be).


AS for the amount of files, frankly, I prefer editing a small
Makefile.am and generating/deleting *all* these files with a couple of
commands than actually struggling with a large Makefile.in trying to
emulate the same functionality of automake (e.g. make check, make
dist. etc..). Also, I personally find the process of manually creating
makefiles to be a tedious and a very dull process.


Samy Al Bahra writes:
 > On Tue, 23 Dec 2003 12:09:43 -0800 (PST)
 > automake provides a framework for LARGE projects with a dozen or more
 > source code files, where writing your own Makefile is something not so
 > trivial. automake's simple SOURCES/PROGRAMS/etc... model allows addition
 > and management of such things easy (ONLY because maintaining your own
 > Makefile is relatively much more difficult). A small project like this
 > has no need for automake and the overhead involved with it.

I'm planning to add a more logical structuring to the code
(e.g. qibla/common should have there own files - adding /src
/doc..etc). AFAIK, we're also planning a future merge with the hijri
library. What i'm saying here is that although this project *is*
small, the complexity of it's structure is currently growing and
changing.

 > 
 > So, what does automake provide to this project? It adds management
 > over-head, that's all what it does. Not to note the several errors in
 > the implementation now.
 > 
 > >From Makefile.am
 > -------------------------------------------------------------------
 > CFLAGS = -Wall -g -O2
 > LDADD = -lm
 > -------------------------------------------------------------------
 > 
 > It is not your job to specify cflags such as -g and -O2, this is up to
 > the user and not you. Not all users would like -g, not all systems will
 > execute prayertime with -O2 properly, etc... You cannot blindly assume
 > -lm is laying around as well, you need to take into consideration
 > different possible paths into consideration.
 > 

That was there for testing purposes only. It's not even necessary for
the build process. This was just a lazy replacement for me not using
'export'.

 > 
 > The automake framework that was written does not take LDFLAGS into
 > account. The old build framework that I committed checked is the system
 > was SunOS and added the appropriate linker flags to LDFLAGS. Thamer did
 > not take advantage of this in his automake files.
 > 

Is this impossible to fix or achieve with automake? My guess is that
fixing this would be an easy task.


 > > Could we do this ?  Go back to the previous minimalistic autotools
 > > process and address any concerns you might have (ie. address those
 > > 'error prone' issues) as well as add whatever required features
 > > (not sure what those might be).
 > 
 > The old process is much less error prone than the current cumbersome
 > automake interface. I would like to request the possibility of providing
 > me with the permission to modify source code in this project, initially,
 > portability issues (to fully leverage the power of autoconf).
 > 
 > Thamer, could you please state why you did this? and I urge you to take
 > into consideration other people's thoughts for such courses of action,
 > it is only your job as maintainer to take the best path. It is probable
 > someone did things the way they are for a reason.
 > 

Of course this still up for debate. There are two paths to choose from:

1- I revert the changes to the old working code and we continue
   updating the Makefile.in as necessary. As the library grows and
   changes, Makefile.in editing might become more and more a time
   wasting and a boring task for everyone.

2- Fix the current automake portability issues and then we'll end up
   with a much simpler approach, less human written code to edit and
   a file smaller and easier to maintain in the future to suit the
   library's design.

Because I'm new to Linux programming, I'm quite flexible (but this may
change soon ;), and since you, Samy, are willing to maintain the build
process of this library then of course whatever you decide will be fine
with me.

Regards,

Thamer Mahmoud