From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.15.42.72 with SMTP id t48mr2471007eev.4.1386959900778; Fri, 13 Dec 2013 10:38:20 -0800 (PST) Path: border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!i6no8298549wiy.1!news-out.google.com!bd4ni8705wib.0!nntp.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: =?UTF-8?B?QmrDtnJu?= Persson Newsgroups: comp.lang.ada Subject: Re: CPAN style Ada repository Date: Fri, 13 Dec 2013 19:38:18 +0100 Message-ID: <20131213193818.5b503dfe@hactar.xn--rombobjrn-67a.se> References: <52976431$1@news.actrix.co.nz> <20131211214934.690d2601@hactar.xn--rombobjrn-67a.se> <85r49iyrnf.fsf@stephe-leake.org> Mime-Version: 1.0 X-Trace: individual.net nukiB9apw/hK5kGNlwFpZwWu6PePF8QFvVMedOfVwtqNbFO2Fw Cancel-Lock: sha1:62zDeTlHobnlKTYRGlBoPqTejpg= X-Newsreader: Claws Mail 3.9.2 (GTK+ 2.24.22; x86_64-redhat-linux-gnu) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Original-Bytes: 3557 Xref: number.nntp.dca.giganews.com comp.lang.ada:184254 Date: 2013-12-13T19:38:18+01:00 List-Id: Stephen Leake wrote: > Bj=C3=B6rn Persson writes: > > Support the GNU standard directory variables so that your software > > can be installed in different systems with different filesystem > > layouts: prefix, exec_prefix, bindir, libdir, libexecdir and all > > the others as appropriate for the types of files that your project > > installs.=20 >=20 > I would leave "install" to the packagers; upstream Makefiles should > just build in place. I disagree with that for the following reasons: =C2=B7 The directory variables aren't used only for copying files in the installation step. Some of these pathnames sometimes need to be embedded in programs so that they'll know where to find data files or other programs. =C2=B7 Some of the directory variables also need to be embedded in librarie= s' usage project files. Packagers will have to patch usage projects if the upstream build system doesn't configure them correctly, and patches are much more of a maintenance burden than command line parameters are. =C2=B7 Libraries need some source files installed, but usually not all of the source files. At least some specifications are always needed, but sometimes bodies are also needed, if they contain generic units or inline subprograms. Manually keeping track of which files are needed is difficult, especially for a packager who isn't also an upstream developer, but the GNAT builders know which files are needed and can install them for you. =C2=B7 Packagers aren't the only ones who will build your software. Users w= ho download the source tarball and install locally won't like to dig files out of the source tree manually and edit project files. > > Writing such a flexible makefile is of course nontrivial work that > > you don't want to do over and over. You can avoid most of the work > > by using Comfignat (https://www.rombobj=C3=B6rn.se/Comfignat/). > > Comfignat gives you all of the above, except that limitations in > > Gnatmake's and GPRbuild's command line syntax prevent it from > > automatically supporting LDFLAGS and GNATBINDFLAGS when libraries > > are built. >=20 > I haven't looked at this yet. But it sounds like an Ada-style > alternative to automake, which is very welcome. Yes, that's a good comparison. The purpose of Comfignat is similar to that of Automake, but the way it works is somewhat different. You import a generic makefile instead of generating a makefile, and it delegates dependency tracking to GPRbuild or Gnatmake. Bj=C3=B6rn Persson