Re: [Gnucap-devel] Makefiles again

[al davis]

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.