<div dir="ltr">I am an advocate of scons, here is why:<div><br></div><div>1. build file is python so you have a very rich (yet simple) language to specify rules.</div><div>2. it detects changes in rules and will build when a build rule changes, not just when source changes.</div><div>3. by default it uses checksums to determine when source changes (more reliable than timestamps). you can configure to use timestamps.</div><div>4. It puts all the rules in a database; this means that the rules are well controlled. The database is an sqllite database.</div><div>5. Code generators can be built in python and included as a library so that code generation is graceful.</div><div>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. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 5, 2017 at 12:27 PM, Chris Fowler <span dir="ltr"><<a href="mailto:cfowler@outpostsentinel.com" target="_blank">cfowler@outpostsentinel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:#000000"><div><br></div><div><br></div><hr id="m_-288886528175170691zwchr"><div><blockquote style="border-left:2px solid #1010ff;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"DJ-Pfulio" <<a href="mailto:DJPfulio@jdpfu.com" target="_blank">DJPfulio@jdpfu.com</a>><span class=""><br><b>To: </b>"Atlanta Linux Enthusiasts" <<a href="mailto:ale@ale.org" target="_blank">ale@ale.org</a>><br></span><b>Sent: </b>Sunday, February 5, 2017 5:10:39 AM<span class=""><br><b>Subject: </b>Re: [ale] Including Makefile<br></span></blockquote></div><div><blockquote style="border-left:2px solid #1010ff;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt">It has been 15 yrs since I did any non-trivla Makefiles.<span class=""><br><br>We always had 1 Makefile.inc for each C++ project, but every directory<br>had its on Makefile. We would chdir into each subdirectory and build<br>using the Makefile there (higher level Makefile did this), not a<br>recursive include. Did some fairly large projects that way - 4-teir<br>stuff. Builds for 12 different platforms controlled by gmake (including<br>Windows).<br><br>We didn't use symlinks - at the time, Windows didn't support that.<br><br>Might not help you.<br></span></blockquote><div><br></div><div>In this project I have 400+ Makefiles. Additional 200 that would have been, but I created a bash script instead.</div><div><br></div><div>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. </div><div><br></div><div>There is a subdir for each package in this tree. Some even go deeper.</div><div><br></div><div>perl-modules</div><div> modules</div><div> <200> dirs here.</div><div><br></div><div>A lot of this is clean up work to reign in the management headaches of those old ways of doing things.</div><div><br></div><div>An example with openssl</div><div><br></div><div>Old:</div><div> openssl-X.X.X</div><div> <all the files needed> configure, Makefile, etc. </div><div><br></div><div>New:</div><div> openssl-X.X.X</div><div> src</div><div> openssl-x.x.x.tar.xz (As downloaded from Internet)</div><div> Makefile</div><div><br></div><div><br></div><div>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.</div><div>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. </div><div><br></div><div>Install creates</div><div><br></div><div>openssl-x.x.x:</div><div> build/openssl-x.x.x (unpacked tarball)</div><div> build/target/openssl-x.x.x-n (PKG name DESTDIR)</div><div> pkg/openssl-x.x.x-n.tar.xz (Results of the build ready for install)</div><div><br></div><div>Last thing make install does is to install that tarball as a package, after it removes what may have</div><div>been there.</div><div><br></div><div>No more nightmare and it is a great dream!</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>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.......</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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. :)</div><div><br></div><div><br></div><div><br></div></div></div></div><br>______________________________<wbr>_________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/<wbr>listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/<wbr>listinfo</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Michael Potter<br> Tapp Solutions, LLC</div><div> <a href="http://www.tappsolutions.com" target="_blank">www.tappsolutions.com</a><br>+1 770 815 6142 ** Atlanta ** <a href="mailto:michael@potter.name" target="_blank">michael@potter.name</a> ** <a href="http://www.linkedin.com/in/michaelpotter" target="_blank">www.linkedin.com/in/michaelpotter</a></div><div>Schedule a meeting with me: <a href="https://calendly.com/michael-potter" target="_blank">https://calendly.com/michael-potter</a><br></div></div></div></div></div></div></div>
</div>