[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] Makefiles again
From: |
al davis |
Subject: |
Re: [Gnucap-devel] Makefiles again |
Date: |
Mon, 9 Feb 2015 21:37:53 -0500 |
User-agent: |
KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) |
Before responding further, I need to restate:
> I don't want to get rid of it. I want to use it in a more
> structured, more modular way, that isn't in the way.
I want to look at it from this perspective. Other things seem
to be higher priority now and I want to make the move and not
need to back it out again.
On Monday 09 February 2015, Felix Salfelder wrote:
> i do not understand the three makefile approach. but we had
> that. it sounds fun. lets go on with a few simple aspects.
Simple modularity, an important concept in all programming.
Autotools has that hiding in the mess.
> currently Make2 includes rules, something about .cc.o:. is
> this considered configuration?
Could be, and I thought so at the time. It's different in
Windows, and looking back to its origin, VMS.
> what about a "Makefile"? is this supposed to just include the
> other ones? should configure create it?
>
> > Originally I would hand edit Make2, and often I still
> > prefer to do that.
>
> so Make2 is not there before configure has run, and
> (optionally) edited by hand. and somehow included if you
> type "make"... what will a configure run do to your hand
> crafted Make2?
Clobber it, but that's ok. The idea is to preserve the ability
to tinker with it, mostly for development.
> > The way I want to use autotools is to generate Make2, and
> > use its version of Make3.
>
> usually, configure creates the makefiles. is this what you
> mean? where does Make3 come from?
Make3 is constant. It has all the stuff that is just copied in.
> > As it stands, it actually sort of does that, but then
> > scrambles it all up into a big mess, and scatters it all
> > over the project root directory.
>
> the amount of user serviceable parts is small, which i think
> is most important. the amount of mess... well i don't care,
> as long as it works.
I don't care if I don't have to deal with it. It's the scatter
part that is a problem. It is not clear which parts are user
serviceable and which are not.
But I agree that the amount of truly user serviceable parts is
small.
> > The removal was because I couldn't figure out how to deal
> > with plugins properly, and it was easy with plain old
> > make.
>
> we had that. i simply don't get what you mean. what does
> *not* work for you with the current autotools branch? is it
> just the missing Make2? dissecting/renaming some files will
> not immediately add functionality.
On that topic, the way plugins are handled now, autoconf or not,
is not what it should be. So I want to deal with the plugin
handling first in a simpler environment, then fold it into
autoconf.
The problem .. I am remembering the trouble before, when I was
working on the split build. When I was doing the work, autoconf
just got in the way.
What does not work in the current autotools branch? There's an
easy bug that the m4 directory is missing, then when I make and
make install just taking defaults and run it, it says:
"gnucap: error while loading shared libraries: libgnucap.so.0:
cannot open shared object file: No such file or directory"
I want to try what I suggested, but have too many other things
to do first. I can see that I will need to spend some time with
it. Maybe trying it will show that it is a bad idea. Maybe it
will just give me a better understanding of autotools.
It may not be apparent, but I really do appreciate the work you
did to get it this far. Same to Dan for the previous
configuration. I would not have had the patience to do it
alone.