[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Prayertime autotools (again)
- To: Development Discussions <developer at arabeyes dot org>
- Subject: Re: Prayertime autotools (again)
- From: Thamer Mahmoud <neokuwait at hotmail dot com>
- Date: Thu, 25 Dec 2003 16:20:32 +0300
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'.
> > 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.
>
> 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.
>
> > 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.
>
> --
> +-----------------------------------+
> | Samy Al Bahra | samy at kerneled dot com |
> |-----------------------------------|
> | B3A7 F5BE B2AE 67B1 AC4B |
> | 0983 956D 1F4A AA54 47CB |
> |-----------------------------------|
> | http://www.kerneled.com |
> +-----------------------------------+
> _______________________________________________
> Developer mailing list
> Developer at arabeyes dot org
> http://lists.arabeyes.org/mailman/listinfo/developer