Paul Smith psm...@gnu.org writes:
As for why 3.82 is slower, unfortunately I'm having problems figuring it
out. I compiled with gprof but the cumulative profiled code in GNU make
only took 6 seconds or so, so I suppose the other 24 seconds must be in
libc or someplace... but trying to install
Patrick Rutkowski rutsk...@gmail.com writes:
I don't get from that page how to apply to all my $(CC) build
commands, and I really want to quiet down this very messy make
output I now have.
When silent-rules is enabled, you don't need to do anything special in
Makefile.am for normal commands
Patrick Rutkowski rutsk...@gmail.com writes:
I don't get from that page how to apply to all my $(CC) build
commands, and I really want to quiet down this very messy make
output I now have.
When silent-rules is enabled, you don't need to do anything special in
Makefile.am for normal commands
On Sat, Nov 13, 2010 at 5:19 AM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
It might be time to reconsider this decision.
If we document it, we should at least advise against it IMHO.
... or just give the pros and cons. That seems likely to be more
convincing and less annoying...
MK halfcountp...@intergate.com writes:
Ah, it's because of GNU make:
No it's not.
By default, the Make rules should compile and link with -g, so that
executable programs have debugging symbols. Users who don't mind being
helpless can strip the executables later if they wish.
Nice,
MK halfcountp...@intergate.com writes:
If you say so, then I guess I am imagining things ;) I have never
given the issue much thought until now, I suppose I need to do a bit
more research on the issue.
Indeed, it's often a good idea to do the research _before_ posting
flames and rants...
John Calcote john.calc...@gmail.com writes:
You need to remember the original target audience of GNU software was
a group of people that wanted to share free software. Most of them
were students or researchers that generally built software distributed
in source form.
...
That being the case,
k...@freefriends.org (Karl Berry) writes:
I personally would not have written it that way in the first place, but
given that it is there now, I don't want to simply replace it with bland
text, or occupy rms's time with it, either.
Yeah, I think there's nothing particularly offensive about that
On Tue, Jan 4, 2011 at 10:22 AM, Xan Lopez x...@gnome.org wrote:
Do you know _what_ is taking so long? I mean, disk I/O (stats on a cold
disk cache), user CPU time (inefficient algos in make), system CPU time
(stats on a warm disk cache)...?
Are you talking about the time to process those
On Fri, Jan 7, 2011 at 8:18 AM, Xan Lopez x...@gnome.org wrote:
I haven't tested it personally, but I can ask. What I know is that
Chromium uses gyp, which on Linux generates Makefiles, and they claim
their null-build time is pretty much zero (not sure on which machine,
though, so perhaps
On Fri, Jan 7, 2011 at 8:34 AM, Xan Lopez x...@gnome.org wrote:
Do they actually do the same thing?
Yes, we all build WebKit + the some testing tools. The set of files we
build is not identical, since it changes by port, but the difference
is negligible since most of the files are
Xochitl Lunde xochitl_lu...@tripplite.com writes:
I see that I can get the source, but I don't want to have to compile this
thing if it's not purely script based.
AFAIK, quagmire requires nothing other than GNU make (that was, I guess,
the point of it)...
Also when I go to quagmire-discuss,
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes:
Usually the solution to this is to install and run ntp (Network Time
Protocol, as offered by 'xntp') on the machines on your network.
Is that really a solution? Running ntp makes it a lot more _likely_
that machines will appear to be
hmm, is the tupfile syntax really as horrible as it looks?
[ from the examples page:
: hello.c | gcc -Wall -c hello.c -o hello.o | hello.o
]
-miles
--
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.
Ralf Hemmecke hemme...@gmail.com writes:
Sure. But it is also relevant if one developer adds a macro which is
only available in some recent version of automake, say. Another
developer might not yet have that automake version.
It doesn't really seem any worse than _any_ potential tool
Ralf Hemmecke hemme...@gmail.com writes:
Is there actually a good reason, why the autotools are distributed as
separate packages (autoconf, automake, libtool, m4)? (Maybe even
pkg-config, but I still don't yet know exactly whether it is good for
me.)
Hmm, why not? Isn't it good general
Jef Driesen jefdrie...@hotmail.com writes:
is pkg.m4 in /usr/share/aclocal ?
No. I suppose that file is only present if pkg-config is installed?
I'm trying to build on Mac OS X in case that would matter.
I use some hacks to make the resulting configure script work even if
autoconf can't find
Jef Driesen jefdrie...@hotmail.com writes:
Isn't it easier to just check for the presence of the header file and/or
the library file, avoiding pkg-config entirely?
Well, I'd prefer not to guess when possible, and not using pkg-config
for a package that wants you to use it means you end up
Jef Driesen jefdrie...@hotmail.com writes:
I'm aware of the advantage of using pkg-config. I even supply the *.pc
files for my own projects. But the point is that if I want to support
systems that don't have pkg-config installed (like Mac OS X in my
case), I have to provide a fallback with
Miles Bader mi...@gnu.org writes:
I don't even try to fully support systems without pkg-config, I
basically just want a fallback so I can get some sort of build on them,
maybe with some features disabled.
I should note that although this is my tactic, it's not actually a very
important point
Roger Leigh rle...@codelibre.net writes:
This is not meant to sound like a troll, but: is anyone really
*really* using static linking in 2011?
Sure; it's very useful for specialized libraries that won't be widely
used enough to merit the effort to build and install as dynamic
libraries.
Harlan Stenn st...@ntp.org writes:
Larry McVoy once said something like In theory, theory and practice are
the same. But in practice, they are not.
Maybe he did say that at some point, but it's a hoary old quote
(attributed to Yogi Berra, among others), and certainly didn't originate
with
On my own real projects (the ones with real users), I view the version
control logs as messages for active developers and ChangeLog as messages
for users and occasional developers. So git sees small one-off messages
on a regular basis, and the ChangeLog is updated when big user-visible
Dave Hart davehart_gmail_exchange_...@davehart.net writes:
If anyone knows of examples of
non-recursive Makefile implementations that manage to preserve the
recursive make property of being able to make in a subdir to make a
subset, please share so we can learn from their pioneering.
Could
Antonio Diaz Diaz ant_d...@teleline.es writes:
Three years and three stable releases have passed since a patch (by
Jan Engelhardt) adding dist-lzip support to Automake was sent to this
mailing list[1], but Automake 1.11.2 doesn't yet mention lzip
anywhere. By contrast xz support was added when
Dave Hart daveh...@gmail.com writes:
True, but most C/C++ #includes orders of magnitudes more lines than
they contain themselves, so assuming the source code is rearranged to
have a precomp.h containing the bulk of #includes, the compile will
be notably faster.
Faster enough to be worth the
2011/12/26 Olaf van der Spek m...@vdspek.org:
Faster enough to be worth the annoyance for the developer of twisting
his source code to fit the pch style (which seems notably uglier)?
Yes
I'm not sure what twisting you're referring too though.
Another comment noted that PCH was often
2011/12/26 Olaf van der Spek m...@vdspek.org:
On Sun, Dec 25, 2011 at 5:31 PM, Miles Bader mi...@gnu.org wrote:
2011/12/26 Olaf van der Spek m...@vdspek.org:
Faster enough to be worth the annoyance for the developer of twisting
his source code to fit the pch style (which seems notably uglier
Daily, Jeff A jeff.da...@pnnl.gov writes:
Yes, all sources must be listed, AFAIK. You could write your own build
rules and targets for these files, which would be copied by automake into
your eventual Makefile, but that somewhat defeats the purpose of using a
build tool if you're writing many
Bill Sacks sa...@ucar.edu writes:
The dependency issue that Jeff raised is not a problem for us, since
we have a script to determine Fortran 90 dependencies.
I'm not sure that it will work to have a separate library of the
user-added code, since we don't know ahead of time what dependencies
Stefano Lattarini stefano.lattar...@gmail.com writes:
Still, things are not as easy as it would appear from your sample project.
For example, with this rule:
$(CC) -c $(CFLAGS) -DIM_STUUPD=1 $
you are losing some important features offered by automake -- most
notably, the automatic
Nick Bowler nbow...@elliptictech.com writes:
Interestingly, if you actually stick a line exactly like the above into
your Makefile.am, Automake will actually do The Right Thing™ and
creates the .Po stub as if you had actually specified the source file
normally. Presumably you'd be relying on
2012/1/20 Bob Friesenhahn bfrie...@simple.dallas.tx.us:
One interesting thing would be to add some simple automake feature to
allow specifying this stuff explicitly via some interface
(e.g. AM_EXTRA_SOURCE_FILES([blah.c barf.h]) in configure, or something
like that). That might make it
I thought that as long as one used .la libraries, automake+libtool
was supposed to handle all the grotty stuff like rpath automatically,
adding -rpath $(libdir) if you depend on libraries installed to libdir
and libdir isn't on the system library search path. [Yeah, I also
know some people hate
2012年2月27日0:58 Peter Johansson troj...@gmail.com:
On which system do you experience this? I've seen this problem on
Fedora and the problem was that the linker search path and the dynamic
loader search path were different. IIUC libtool sets -rpath if a used library
is outside linker path.
2012年2月27日1:46 Peter Johansson troj...@gmail.com:
I think it's desirable that it just work wherever it gets installed,
and no matter who installs it (e.g. prefix=$HOME should work, and
shouldn't require setting LD_LIBRARY_PATH).
In my case it did work with prefix=$HOME because in that case
2012年2月27日9:41 Bob Friesenhahn bfrie...@simple.dallas.tx.us:
Just using the command: sudo ldconfig
after installing my package makes everything work!
This is a function that libtool normally performs if it is used properly.
I did: sudo make install
Is that not using it properly?
-miles
2012年2月27日16:21 Russ Allbery r...@stanford.edu:
This is a function that libtool normally performs if it is used properly.
I did: sudo make install
Something needs to run libtool --mode=finish. I thought Automake normally
arranged to run that at the end of make install. Is that not
Stefano Lattarini stefano.lattar...@gmail.com writes:
Any transformation of a $(pkg*dir) by $(program_transform_name)
would be a bug; if you encounter such an issue, I'd be grateful if
you report it.
But I'm pretty sure the inconsistency you are seeing here is due to
another reasons (maybe
Eric Blake ebl...@redhat.com writes:
I think it's worth pursuing a patch to the GNU Coding Standards that
allows a standardized configure option that allows one to specify an
alternate package name, so that things like $(pkglibdir) become
$(libdir)/$(alternate_package_name)
A standardized
Is there a recommended way for dealing with binaries that are simple
shell scripts in automake? I currently use something like the
following:
bin_PROGRAMS = myprog
myprog_SOURCES = myprog.sh
myprog: myprog.sh
%: %.sh
$(shbin_verbose)cp $ $@; chmod +x $@
shbin_verbose
Harlan Stenn st...@ntp.org writes:
What's the problem with bin_SCRIPTS?
Hmm, I didn't know about it, but ... reading the documentation,
bin_SCRIPTS doesn't actually seem to do much of anything -- you
still have to add your own rules to handle all the actual work, need
to fiddle with EXTRA_DIST
2012年3月21日8:33 NightStrike nightstr...@gmail.com:
bin_SCRIPTS doesn't actually seem to do much of anything -- you
still have to add your own rules to handle all the actual work, need
to fiddle with EXTRA_DIST and CLEANFILES, etc. Indeed, doing what I
You can avoid hacking EXTRA_DIST if you
2012年3月21日9:32 NightStrike nightstr...@gmail.com:
dist_bin_SCRIPTS = aaa
That's going to distribute aaa, though, right, not the actual
source e.g. aaa.sh?
Yes. There's an earlier email in this thread from somebody
illustrating that you don't need to morph from source to script if the
file
2012年3月21日13:13 NightStrike nightstr...@gmail.com:
Here's a better question. How do you insure that your current file is
executable? Do it the same way.
Er cp $ $@ chmod +x $@ ... :]
[Relying on source-code execute bits always being correctly maintained
is one of those things that ...
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes:
This is fine and good for scripts which are formally installed, but
while they (originals) are in the source tree, there are definite
benefits for scripts to have a useful extension. This is particularly
true if people build in the source
Russ Allbery r...@stanford.edu writes:
[Relying on source-code execute bits always being correctly
maintained is one of those things that ... well... doesn't really
feel very robust. I dunno, maybe it's just me...]
Doesn't every package with a configure script rely on this? I suppose
that
NightStrike nightstr...@gmail.com writes:
The shell-scripts in question, however, are source files, and so come
directly via whatever mechanism you use to get source files -- tar,
cp, random-vcs-xyz, In many cases such mechanisms can preserve
execute bits, but ... it doesn't feel quite
Pedro Alves pal...@redhat.com writes:
OK, you've all made clear you have your sensible reasons to have the '.info'
...
it available only though the new, undocumented option named (literally)
hack!info-in-builddir. I hope this is acceptable to you.
...
*undocumented* option
songbird songb...@anthive.com writes:
That extra stuff is what will allow your package to work on the
machines of your users without requiring them to have all the
developer's tools you're using (autoconf, automake, aclocal, bison,
flex).
ok. i'm one of those people who hates extra
files
Ralf Corsepius ralf.corsep...@rtems.org writes:
-EFAILMAINTAINER
No need to be obnoxious.
a) This kind of changes is inappropriate within a release series.
b) You don't seem to be aware about the harmfulness of this change of yours.
Please comprend that this change was a mistake and revert
Werner LEMBERG w...@gnu.org writes:
(1) If the user unpacks the tarball, the rules are not executed.
(2) If the user does a bootstrap from the repository to do `make
dist', they are needed.
(3) If the user changes a doc source file in the tarball and wants to
regenerate the
NightStrike nightstr...@gmail.com writes:
suppose that my program is composed of 2 files f1.c and f2.c. f1.c is
written in C89 and f2.c in C99. I would like that f1.c is compiled
with a C89 compiler and f2.c is compiled with a C99 compiler.
How can I achieve that in Makefile.am ?
Also, in
[following up my previously message]
This is an earlier post I made, which analyzes the Lua string library
w/r/t UTF-8:
http://lua-users.org/lists/lua-l/2012-02/msg00241.html
-Miles
--
Selfish, adj. Devoid of consideration for the selfishness of others.
Ralf Corsepius ralf.corsep...@googlemail.com writes:
My issue is ...rantrantblatherblather...
Please start a new thread when your message has bugger all to do with
the previous message.
Thanks,
-miles
--
The car has become... an article of dress without which we feel uncertain,
unclad, and
Ralf Corsepius ralf.corsep...@googlemail.com writes:
Pardon, may-be I am missing something, but in my understanding I am
having the same issue as the OP:
No, you were just looking for an excuse to start ranting...
-miles
--
Yorton, Wressle, and Gospel Oak, the richness of your heritage is
Stefano Lattarini stefano.lattar...@gmail.com writes:
Actually, it depends. Where and why do you use such
dynamically-computed version number in exactly?
That seems the real question.
My own method is to have:
(1) The primary version number is based on VCS info (this is
obviously
Nicolas Bock nicolasb...@gmail.com writes:
libsomething_la_CPPFLAGS = -I../../
...
the naming changed from a.F90 - libsomething_la-a.lo to a.F90 -
a.lo. Very strange.
It's an annoying, but documented, effect of using per-library CFLAGS:
when you do that, automake decides that it must generate
NightStrike nightstr...@gmail.com writes:
If you include src/more/Makefile.am into src/Makefile.am (a perfectly
valid thing to do), you will be unpleasantly surprised that
src/more/Makefile.am has to actually know where it is in the source
tree. It needs lines like this:
prog_SOURCES +=
Stefano Lattarini stefano.lattar...@gmail.com writes:
The best solution is on the user-side IMHO: fix the build system to
use less (ideally none) make recursion. Both the parallel and serial
testsuite harness should support that setup OOTB.
It would be nice if automake had some more features
Stefano Lattarini stefano.lattar...@gmail.com writes:
But what if we want to have multiple betas for, say, Automake 1.14? Today,
we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
you are proposing?
There's always 1.14.0.1, ...
Or the widely used in FOSS 1.13.99...
2013/2/12 Stefano Lattarini stefano.lattar...@gmail.com:
But what if we want to have multiple betas for, say, Automake 1.14? Today,
we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
you are proposing?
There's always 1.14.0.1, ...
Yuck; the new versioning scheme is
2013/2/12 Stefano Lattarini stefano.lattar...@gmail.com:
Mostly fair points; but the biggest issue with this proposal (not
sure why I didn't think of it before, sorry) is that it is not at
all clear that a version like 1.13.0.1 is supposed to be a beta
release. People will easily mistake it
Nate Bargmann n...@n0nb.us writes:
I was advised by a Debian maintainer to use tilde '~' as the
separator as any text following it will be considered older. For
example, in our project 'Hamlib-3.0~git' is older than
'Hamlib-3.0' will be once released. A hyphen or underscore trips
this logic
Stefano Lattarini stefano.lattar...@gmail.com writes:
* maint - master
* master - next
Damn, not really. For some questionable reason, Savannah is rejecting
my non-fast-forward push to master even if I specify '--force', and
I cannot use the usual trick delete the remote branch, then
Just that by far the most common branch setup in git repos seems to be
using master as the dev trunk, with releases, release candidates
(etc) on special branches. There are often additional feature
branches for even more speculative changes, but master is generally
not really safe, even if it's
Stefano Lattarini stefano.lattar...@gmail.com writes:
You might have good points, and possibly even be completely right...
But I must ask, why didn't you step up during the lengthy discussion
about this change, nor objected during the delay (almost a week) that
was deliberately let pass
Stefano Lattarini stefano.lattar...@gmail.com writes:
And while you *might* have changed my mind before (because you have
valid points, and maybe it would have better to err on the side of
safety), I have now already rewritten maint, so rather than messing
up by rewriting it again (to its old
Stefano Lattarini stefano.lattar...@gmail.com writes:
So we should maybe go (after the next major release) with this naming
scheme for the branches?
* maint - for next micro version
* stable - for next minor version
* master - for next major version
That seems to match common
The current _user-interface_ (./configure ...ARGS...; make) also has
the advantage of making it pretty clear where one specifies
configuration options, and retaining those options during normal
rebuilds.
With a make-only approach, where do I specify configuration options?
make OPT1=yes ...? If
Marko Kreen mark...@gmail.com writes:
IMHO, building via portable makefiles is bad idea. For quite simple
reason - user rules. Yes, you can create some default targets that are
generated for user, portably. But as soon as user needs to write own
rules or even write logic in makefile, then
Marko Kreen mark...@gmail.com writes:
My experience adding custom make rules to Makefile.am (which AFAICT,
mostly just passes them through) is that I typically don't need to use
obscure features, mostly it's just bog-standard make rules with some
shell-scripting in the build recipe.
Well,
Andrey Borzenkov arvidj...@gmail.com writes:
Alternative is to place EXTRA_DIST outside of conditionals, but this
is more intrusive probably.
Why do you think it would be more intrusive?
The only function of EXTRA_DIST is to specify files that should be put
in the tarball, for files which
Peter Rosin p...@lysator.liu.se writes:
noone has bothered to check, a user on that platform is going to be
less than impressed and would probably not trust the new micro version
and would thus be inconvenienced indeed.
I think 99.99% of users who download and build packages don't run the
Paul Smith psm...@gnu.org writes:
Other macros might have been created specifically for a given project;
they will be contained in files in that project directory. Other
macros might be defined by other 3rdparty software you are trying to
work with (texinfo, various libraries, etc.) Those
Diego Elio Pettenò flamee...@flameeyes.eu writes:
I would also argue for just using non-recursive automake, but it might be
the least of your problems for now.
Just is probably not the right term, as it generally seems to
require more work to make a good non-recursive build setup with
automake,
Stefano Lattarini stefano.lattar...@gmail.com writes:
It seems to me that the situation there has improved a lot in the
recent years, to the point that recursive and non-recursive build
support is almost on-par (and the non-recursive option is the
recommended one). Or are you referring to
Jeff Squyres (jsquyres) jsquy...@cisco.com writes:
We've been using sym links in the OMPI project for years in order to
compile a series of .c files in 2 different ways. It's portable to
all the places that we need/want it.
Hmm, how about just cp ...? :]
-miles
--
80% of success is just
So what do you think? Is my characterization reasonable/unreasonable,
am I missing something, ... or ...?
Any other opinions?
-miles
--
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.' [NYT]
Jules Colding cold...@venalicium.dk writes:
Anyways, thanks for the advises. I'll read the paper on evil
recursiveness and ponder what to do.
Non-recursive make is indeed a nice paradigm for various reasons,
but if you've read earlier threads on this list, actually
_implementing_ it is not
Stefano Lattarini stefano.lattar...@gmail.com writes:
E.g., if I have a directory foo that has sources etc, and builds
some specific targets, then I can isolate the automake stuff for foo
by using an include file foo/Makefile.am.inc or something, and then
putting an appropriate include in the
%...% seems nice to me.
I don't think typability should be a prime factor in deciding,
especially such trivial issues such as shifted-characters (like 75% of
punctuation in Makefiles is shifted on most keyboards); readability is
_much_ more important (and readability in many cases means not too
... and canon_reldir means the same thing, except canonicalized?
Yes, canonicalized in a sense quite specific to Automake:
http://www.gnu.org/software/automake/manual/automake.html#Canonicalization
So, for example, if %reldir% expands to 'foo/bar-baz.d', '%canon-reldir%'
will expand to
Hmm, if that's the case, then I think canon is the wrong term to
use, as it typically implies that the result is still in the same
domain as the input.
Suggestions for a better name then?
Dunno... something like RELDIR_SYM would make sense ... it's a
symbol corresponding to RELDIR...
2013/2/12 Stefano Lattarini stefano.lattar...@gmail.com:
Mostly fair points; but the biggest issue with this proposal (not
sure why I didn't think of it before, sorry) is that it is not at
all clear that a version like 1.13.0.1 is supposed to be a beta
release. People will easily mistake it
Just that by far the most common branch setup in git repos seems to be
using master as the dev trunk, with releases, release candidates
(etc) on special branches. There are often additional feature
branches for even more speculative changes, but master is generally
not really safe, even if it's
Stefano Lattarini stefano.lattar...@gmail.com writes:
And while you *might* have changed my mind before (because you have
valid points, and maybe it would have better to err on the side of
safety), I have now already rewritten maint, so rather than messing
up by rewriting it again (to its old
Stefano Lattarini stefano.lattar...@gmail.com writes:
So we should maybe go (after the next major release) with this naming
scheme for the branches?
* maint - for next micro version
* stable - for next minor version
* master - for next major version
That seems to match common
Stefano Lattarini stefano.lattar...@gmail.com writes:
Any transformation of a $(pkg*dir) by $(program_transform_name)
would be a bug; if you encounter such an issue, I'd be grateful if
you report it.
But I'm pretty sure the inconsistency you are seeing here is due to
another reasons (maybe
Eric Blake ebl...@redhat.com writes:
I think it's worth pursuing a patch to the GNU Coding Standards that
allows a standardized configure option that allows one to specify an
alternate package name, so that things like $(pkglibdir) become
$(libdir)/$(alternate_package_name)
A standardized
Pedro Alves pal...@redhat.com writes:
OK, you've all made clear you have your sensible reasons to have the '.info'
...
it available only though the new, undocumented option named (literally)
hack!info-in-builddir. I hope this is acceptable to you.
...
*undocumented* option
... and canon_reldir means the same thing, except canonicalized?
Yes, canonicalized in a sense quite specific to Automake:
http://www.gnu.org/software/automake/manual/automake.html#Canonicalization
So, for example, if %reldir% expands to 'foo/bar-baz.d', '%canon-reldir%'
will expand to
92 matches
Mail list logo
