[ale] Including Makefile

[Chris Fowler]

> From: "DJ-Pfulio" <DJPfulio at jdpfu.com>
> To: "Atlanta Linux Enthusiasts" <ale at ale.org>
> Sent: Sunday, February 5, 2017 5:10:39 AM
> Subject: Re: [ale] Including Makefile

> It has been 15 yrs since I did any non-trivla Makefiles.

> We always had 1 Makefile.inc for each C++ project, but every directory
> had its on Makefile. We would chdir into each subdirectory and build
> using the Makefile there (higher level Makefile did this), not a
> recursive include. Did some fairly large projects that way - 4-teir
> stuff. Builds for 12 different platforms controlled by gmake (including
> Windows).

> We didn't use symlinks - at the time, Windows didn't support that.

> Might not help you.

In this project I have 400+ Makefiles. Additional 200 that would have been, but I created a bash script instead. 

I'm working in a tree that has 20 years of history. Some code is that old. Most of it is not. The ideas of managing the tree are that old. 

There is a subdir for each package in this tree. Some even go deeper. 

perl-modules 
modules 
<200> dirs here. 

A lot of this is clean up work to reign in the management headaches of those old ways of doing things. 

An example with openssl 

Old: 
openssl-X.X.X 
<all the files needed> configure, Makefile, etc. 

New: 
openssl-X.X.X 
src 
openssl-x.x.x.tar.xz (As downloaded from Internet) 
Makefile 

In the old way we would compile and then loop back around and "install". That has always been a problem because some packages need others. 
In those cases we'd include the directories of the dependents in their build. Over 20 years libtool created problems because finalization is done durnig 'make install' of the package using libtool like that. A real nightmare. In the new you can only install. You either make clean or make install. 

Install creates 

openssl-x.x.x: 
build/openssl-x.x.x (unpacked tarball) 
build/target/openssl-x.x.x-n (PKG name DESTDIR) 
pkg/openssl-x.x.x-n.tar.xz (Results of the build ready for install) 

Last thing make install does is to install that tarball as a package, after it removes what may have 
been there. 

No more nightmare and it is a great dream! 

My idea on the include file is that openssl's parent has an include file that I wanted all to use. I was thinking up a way I could force the include in case someone forgot. Links would work. The file idea could allow me to add stuff pertinent to that child off the main directory. I was working on cleanup of an image that contains all the tools needed to compile for the avr, including the arduino API when needed. Converting from the old to the new was great. 1000s of files now down to < 30. At this point I've modified many of our makefiles before. Occasionally I added a few targets unpack,pack,and replace. The first two pack and unpack the src tarball in the src dir. Unpack if I need to make mods. We don't want to make mods to the build of the xample above. In some cases I'm working with the old method that I created a tarball from and have to look at it. In some cases it is our code and I want to make mods. The last, replace, scp's the pkg result to me lab device, removes the old, and installs it. This allows me to not flash firmware and reboot. I thought about just adding those targets to the include instead. 

The end result may be that almost all makefiles eventually go away. Our of 400 almost the content of those is 80% identical. Natural progression with something like that is that I move to the ideas of PKGBUILD, debian/rules, rh.specs....... 

The conversion work has been brutal, but we are reaping rewards now. The final target dir that is converted in firmware is no longer really the final. It is that developer's target and when they create the firmware rsync creates a copy and then a script creates the image from that. The new final stage removes packages not required. This was not possible before because there was no package management. If you did do this you had to know the files within a package that you wanted to remove. Kernel headers is in the target because the build needs it. The final target removes it by the package name of 'kernel-headers', Just like any distribution would. Perl modules used only for testing removed. Python used for building stuff is removed, etc. Environment variables control the script. It is called prep (prep for image) and PREPKEEPDOCS=1 will keep man pages on it. For development purposes and sometimes I do need to read a man page while I'm working on this stuff. 

I'm also cleaning out bad habits. I've modified a lot of code. I've modified the kernel, drivers in the kernel, and in some cases I've added a debug interface in /proc to those drivers giving me grief. I've modified some of the OSS packages for better behavior in 24x7x365 environments. Typically I'd tag the change in the code. In the new I've ripped out all my changes, restored the tarball, and those changes are in a patch file at the root of that packages' build. I was concerned that I could not fully extract my changed from the kernel tree because of all I had made. I took the original source and used diff like normal. Nervous over nothing. :) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20170205/a41bc00b/attachment.html>