public inbox for newlib-cvs@sourceware.org
help / color / mirror / Atom feed
From: Michael Frysinger <vapier@sourceware.org>
To: newlib-cvs@sourceware.org
Subject: [newlib-cygwin] libgloss: add a little build system generation documentation
Date: Tue,  1 Mar 2022 00:05:58 +0000 (GMT)	[thread overview]
Message-ID: <20220301000558.515FD3858421@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=ed459780f4d21ff6c691ec1f0fb64be5ad9671a1

commit ed459780f4d21ff6c691ec1f0fb64be5ad9671a1
Author: Mike Frysinger <vapier@gentoo.org>
Date:   Thu Feb 24 23:43:06 2022 -0500

    libgloss: add a little build system generation documentation
    
    This is a bit of an abbreviated form of what's in the Newlib subdir,
    but with emphasis on Libgloss-specific parts, and anything unique to
    it.  I haven't put too much effort in.

Diff:
---
 libgloss/doc/porting.texi | 50 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/libgloss/doc/porting.texi b/libgloss/doc/porting.texi
index 21b2f565a..5325fb2ed 100644
--- a/libgloss/doc/porting.texi
+++ b/libgloss/doc/porting.texi
@@ -14,6 +14,10 @@
 @global@parindent=0pt
 @end iftex
 
+@set autoconf @ref{Top,,GNU Autoconf,autoconf}
+@set automake @ref{Top,,GNU Automake,automake}
+@set libtool @ref{Top,,GNU Libtool,libtool}
+
 @titlepage
 @title Embed With GNU
 @subtitle Porting The GNU Tools To Embedded Systems
@@ -242,7 +246,7 @@ mostly for Unix based systems.
 @section Configuring and building libgloss.
 
 Libgloss uses an autoconf based script to configure. Autoconf scripts
-are portable shell scripts that are generated from a configure.in file.
+are portable shell scripts that are generated from a configure.ac file.
 Configure input scripts are based themselves on m4. Most configure
 scripts run a series of tests to determine features the various
 supported features of the target. For features that can't be determined
@@ -353,6 +357,50 @@ the dependencies for the @code{all} target and add
 target.  Now, when libgloss is built and installed, support for your
 BSP will be installed as well.
 
+@node Build System Internals
+@section Build System Internals
+
+As noted previously, Libgloss uses GNU Autotools (@value{autoconf} &
+@value{automake}) to build.  @value{libtool} is not used as Libgloss only
+produces objects and static archives, and @value{automake} is capable of
+handling that.
+
+If you're editing any of these files and want to regenerate them, simply run
+@code{autoreconf}.  It will take care of the rest.
+
+Tool versions are strictly controlled.  You must use GNU Autoconf 2.69 and GNU
+Automake 1.15.1 to generate the build files.  If your system does not include
+them, you can manually download and install them into your home directory.
+
+All of the common configure logic lives in @file{configure.ac}.  It checks for
+supported targets and creates the makefiles.  Any architecture that wishes to
+run custom configure tests should store them in @file{acinclude.m4} in their
+respective subdirectory and then use @code{m4_include} in @file{configure.ac}.
+Make sure to avoid running excessive tests for all targets, and avoid using
+generic names that can collide with other architectures -- the build uses a
+flat namespace that is shared among everyone.
+
+Libgloss has partially converted to @value{automake}.  The top-level directory
+uses it with @file{Makefile.am}, as do a few subdirectories with their
+@file{Makefile.inc} fragments.  The other subdirectories still use hand written
+@file{Makefile.in} files.  One day, they should get converted over too.
+Patches welcome!
+
+For directories that have converted to @value{automake}, a non-recursive build
+is used.  That means only a single Makefile is created in the top-level, and no
+Makefiles are created in subdirectories.  Make must be run in the top-level at
+all times.
+
+The @file{config/*.mh} and @file{config/*.mt} files are only used by the non-
+Automake files (i.e., the @file{Makefile.in} files).  They can be ignored for
+any target that has migrated to @value{automake}.
+
+Libgloss automatically builds itself for all multilib configurations that the
+active toolchain supports.  This logic is provided by common code from the
+combined toolchain source tree.  This should @strong{not} be confused with the
+Libgloss-specific @file{multi-build.in} file.  That is used by a few ports to
+further produce multiple targets.
+
 @node GCC, Libraries, Libgloss, Top
 @chapter Porting GCC


                 reply	other threads:[~2022-03-01  0:05 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220301000558.515FD3858421@sourceware.org \
    --to=vapier@sourceware.org \
    --cc=newlib-cvs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).