[ale] Including Makefile

Mon Feb 6 08:45:25 EST 2017

I am an advocate of scons, here is why:

1. build file is python so you have a very rich (yet simple) language to
specify rules.
2. it detects changes in rules and will build when a build rule changes,
not just when source changes.
3. by default it uses checksums to determine when source changes (more
reliable than timestamps).  you can configure to use timestamps.
4. It puts all the rules in a database; this means that the rules are well
controlled. The database is an sqllite database.
5. Code generators can be built in python and included as a library so that
code generation is graceful.
6. and the one that really saves time: reliably detects relationship of
header files so the header file rules do not need to be hand coded.

On Sun, Feb 5, 2017 at 12:27 PM, Chris Fowler <cfowler at outpostsentinel.com>
wrote:

>
>
> ------------------------------
>
> *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. :)
>
>
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>

-- 
Michael Potter
  Tapp Solutions, LLC
   www.tappsolutions.com
+1 770 815 6142  ** Atlanta ** michael at potter.name  **
www.linkedin.com/in/michaelpotter
Schedule a meeting with me: https://calendly.com/michael-potter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20170206/108e1f4a/attachment.html>