Pathlevel versions expected to be backward _and forward_ compatible. I.e.
if something works on version M.N.P, then it expected to work on both
M.N.P+1 and M.N.P-1 (modulo bug fixes, of course).
Adding new features (e.g. Algol support) isn’t such change — if it added in
version M.N.P, then scripts
vel librsvg.a correctly, out of
> a bunch of .o files and a librsvg_internals.a library that is already
> PIC-compiled?
>
> (This also breaks --disable-shared for the configure script.)
>
> Any suggestions are appreciated.
>
> (For reference, this is mentioned in both
> https://gitlab.gnome.org/GNOME/librsvg/issues/159 (Linux) and
> https://github.com/Homebrew/homebrew-core/issues/23772 (MacOS)).
>
> Thanks,
>
> Federico
>
>
>
>
--
Andrew W. Nosenko
ource
> directory?
>
Put them into static or libtool "convenience" libraries and override CFLAGS
on per-library basis.
--
Andrew W. Nosenko
where automake runs a single test called
> 'testsuite', but 'testsuite' itself can run multiple tests in series or
> parallel).
>
Yes, sorry, I indeed forgotten that my testsuite uses autotest instead of
automake's framework.
Sorry for the noise.
--
Andrew W. Nosenko
hort answer is because I wanna use 8 cpus. There is no sensible way
> Automake can know how many cpus I wanna use.
>
$ make check TESTSUITEFLAGS=-j8
--
Andrew W. Nosenko
with
> -Wobsolete? And add to the message that support will be removed in
> 1.14.
Show warning always may be overkill, but wait one more release would
be very nice IMO considering that warnings were efficiently "muted" by
'foreign' strictness till the automake-1.12
--
Andrew W. Nosenko
and
> there's less to keep track of for the programmer
>
Placing shell script under *_PROGRAMS variable may break 'install-strip' target.
Just because strip(1) (or 'install -s', if more preciously) don't know
how to strip them.
--
Andrew W. Nosenko
te target.
>
> Moreover, the use of GNU make-specific pattern rules here is pointless
> because the same can be accomplished by a more portable single-suffix
> rule.
>
> Better to write it as follows:
>
> SUFFIXES = .sh
>
> .sh:
> $(shbin_verbose) cp $< $@
On Thu, Jun 23, 2011 at 16:59, Bob Friesenhahn
wrote:
> On Thu, 23 Jun 2011, Andrew W. Nosenko wrote:
>>
>> Hmmm... What about do not enforce any particular format by default?
>> Especially if consider that on my FreeBSD automake already enforses
>> ust
issing --run tar chof - "$tardir" | bzip2 -9
-c >testprog-0.0.0.tar.bz2
The 'o' option in the 'tar chof -' above means '-‐format ustar' for
bsdtar instead of '--format v7' for GNU tar :-)
--
Andrew W. Nosenko
n't add
anything to the my question: how you plan to handle inter-library
dependencies on the systems where ld.so does NOT support such things?
And it is just one and _very_ simple question.
PS. I totaly agree that .la in theirs current form are not very
convinient. Indeed, not the .la itself, but the way, how libtool
works with them. But instead of discussing whether to remove them, I
would prefer to see discussion, how to make libtool more convinient
(more ld(1) like, i.e. how to support access to the
/path/to/libname.la as -L/path/to -lname instaed of forcing to specify
the full path with full name.)
--
Andrew W. Nosenko
epends on library libA. libA depends on libB.
Then you need to link both libA and ibB into your app even if app
itself needs libA only and know nothing about libB.)
--
Andrew W. Nosenko
ess GLR-targeted .y source
anyway. Just threat bison like would be threated any another custom
(unsupported especially by autoconf/automake) preprocessing tool.
The same related to the classic Lex vs. Flex.
--
Andrew W. Nosenko
gt; the .info file isn't removed but the .pdf file and the Makefile are removed.
> I am suprise to see my Makefile disappears and I must run the configure
> script in order to build it again.
> The only way I found to remove my .info file is to call the rm command
> manually.
>
> What target can help me to remove the .info file built with the make command?
> Why the Makefile is removed when I call the distclean target?
About Makefile see above.
--
Andrew W. Nosenko
And
so on and so on...
Therefore, the safest way is to link your "framework" into main
process (and only into main process) and let the main process to
provide these "framework" functions to the modules loaded by him.
--
Andrew W. Nosenko
flavors and
distros).
--
Andrew W. Nosenko
nsider "do not delete
distributed files" as reasonable and expected by users behavior.
Therefore proposal: exclude all files listed in the EXTRA_DIST from
the any generated "clean"-like targets (except maintainer-clean, if
any).
--
Andrew W. Nosenko <[EMAIL PROTECTED]>
17 matches
Mail list logo
