Re: GNU APL build system changes

[Bill Heagy]

On debian 32-bit:

make
[.....]
mv -f .deps/apl-LvalCell.Tpo .deps/apl-LvalCell.Po
g++ -DHAVE_CONFIG_H -I. -I..    -Wall -I sql -I 
/home/wheagy/tmp/apl_svn/trunk     -I/usr/include     -g -O2 -I 
/home/wheagy/tmp/apl_svn/trunk -MT apl-Macro.o -MD -MP -MF 
.deps/apl-Macro.Tpo -c -o apl-Macro.o `test -f 'Macro.cc' || echo 
'./'`Macro.cc
mv -f .deps/apl-Macro.Tpo .deps/apl-Macro.Po
g++ -DHAVE_CONFIG_H -I. -I..    -Wall -I sql -I 
/home/wheagy/tmp/apl_svn/trunk     -I/usr/include     -g -O2 -I 
/home/wheagy/tmp/apl_svn/trunk -MT apl-Missing_Libraries.o -MD -MP -MF 
.deps/apl-Missing_Libraries.Tpo -c -o apl-Missing_Libraries.o `test -f 
'Missing_Libraries.cc' || echo './'`Missing_Libraries.cc
Missing_Libraries.cc: In function ‘Token missing_files(const char*, 
const char**, const char**, const char**)’:
Missing_Libraries.cc:90:13: error: ‘CONFIGURE_ARGS’ was not declared in 
this scope
   90 | "      " << CONFIGURE_ARGS << "\n\n";
      |             ^~~~~~~~~~~~~~
make[3]: *** [Makefile:4331: apl-Missing_Libraries.o] Error 1
make[3]: *** Waiting for unfinished jobs....
mv -f .deps/apl-Nabla.Tpo .deps/apl-Nabla.Po
make[3]: Leaving directory '/home/wheagy/tmp/apl_svn/trunk/src'
make[2]: *** [Makefile:5331: all-recursive] Error 1
make[2]: Leaving directory '/home/wheagy/tmp/apl_svn/trunk/src'
make[1]: *** [Makefile:541: all-recursive] Error 1
make[1]: Leaving directory '/home/wheagy/tmp/apl_svn/trunk'
make: *** [Makefile:429: all] Error 2


On 3/27/21 3:00 PM, Dr. Jürgen Sauermann wrote:
> Hi Chris,
>
> it is generally OK to get "*** current directory is not a svn checkout: keeping
> old buildtag"
> if you fetch GNU APL with anything other than SVN, e.g. with git clone or by
> unpacking a tar
> file. At least as long as you don't switch back-and-forth between SVN and git
> with the same
> checkout directory.
>
> However, the fallback file that was used below was incorrect because I had
> forgotten to "git add"
> the buildtag.hh (typical mistake of SVN users where this is automatic).
> Therefore you got your own last
> buildtag (*1410M* from the savannah SVN) instead of my last buildtag (*17930*).
>
> This should be fixed now.
>
> Best Regards,
> Jürgen
>
>
> On 3/27/21 6:54 PM, Chris Moller wrote:
> > Works as well on Fedora release 33, Linux 5.10.17-100.fc32.x86_64 #1 SMP
> >
> > I don't know if it's significant, but I used git clone to pull down the source 
> > code for 1449 and that results in a ./configure message of:
> >
> >     *** current directory is not a svn checkout: keeping old buildtag
> >
> >
> > and an `apl --version` of
> >
> >     BUILDTAG:
> >     ---------
> >         Project:        GNU APL
> >         Version / SVN:  1.8 / 1410M
> >         Build Date:     2021-01-19 19:59:14 UTC
> >         Build OS:       Linux 4.15.0-123-generic x86_64
> >         config.status:  '--enable-maintainer-mode' 'DEVELOP_WANTED=yes'
> >         Archive SVN:    1406
> >
> >
> >
> > On 3/27/21 1:14 PM, Blake McBride wrote:
> > > Builds fine on my 64-bit LinuxMint 19.3 box.
> > >
> > > Thanks!
> > >
> > > Blake
> > >
> > >
> > >
> > > On Sat, Mar 27, 2021 at 12:04 PM Dr. Jürgen Sauermann 
> > > <mail@jürgen-sauermann.de <mailto:mail@j%C3%BCrgen-sauermann.de>> wrote:
> > >
> > >     Hi,
> > >
> > >     as some of you have noticed, I made some changes to the GNU APL build 
> > > system.
> > >
> > >     Some of these changes were simplifications of the build system (some
> > >     automatically
> > >     generated .cc and .hh files like *configure_args.cc* are gone for good),
> > >     while other changes
> > >      were needed to support Autoconf VPATH builds. Also all files generated
> > >     by ./configure
> > >     now stored in the top-level directory so that the subdirectory *src*
> > >     (which is shared by all
> > >     VPATH builds) is no longer muddied with ./configure results.
> > >
> > >     The purpose of VPATH builds is to be able to build several ./configure
> > >     variants in
> > >     parallel. Different VPATH builds are needed to discover build problems,
> > >     in particular with
> > >     rarely used ./configure variants before these problems are committed to
> > >     the savannah
> > >     SVN server.
> > >
> > >     There could still be glitches in the new build structure, so please keep
> > >     reporting
> > >     them.
> > >
> > >     SVN *1449*.
> > >
> > >     Best Regards,
> > >     Jürgen