Re: Building prog first
On Mon, Mar 22, 2010 at 4:44 PM, Reuben Thomas wrote:
> Not true. automake does not have explicit support for building
> programs with the host compiler when cross-compiling, but I
> have done this successfully in the past when I needed precisely
> to build a program on the host when cross compiling, using
> binutils's BFD_CC_FOR_BUILD macro. It's a pity some version of
> this macro isn't in autoconf, or even autoconf-archive; I shall
> do the latter.
I guess this is a hack and a burden to maintain.
When cross-compiling, why compiling a local tool?
Isn't the correct way to natively compile the local tool,
then use it to cross-compile the package?
> This illustrates a weirdness of autotools: poor support for
> installing interpreted languages, and also conversely for
> build-time compiled programs.
Yes, also for coffee-cooking there is poor support only. :-)
I don't think build-time compiled C programs shall be suppored
while cross compiling. I think it already is complex enough.
Otherwise you had to do all checks twice and end up in many
variables with confusing names, and those who are not
cross-compiling probably accidently will mix them.
> > I though of perl, but (A), i don't like slow tools,
(I think Perl is fast)
> > (C), i find making build-programs
> > in C much more concise than scripting and i can debug it in ddd/gdb.
You can debug Perl in DDD.
> This is interesting, as it doesn't match mine or
> commonly-reported experience (translating my build-time
> programs from C to Perl made them shorter, easier to read and
> fix, and no slower to run, although I wasn't doing more than
> grepping 15k lines of C and writing some of it back out again).
$ time perl -e \
'for($n=0;$n<45;$n++) { printf "%08d %60s EOL\n", $n, ""; }' > x
real0m0.713s
$ cat x.c
#include
int main(void)
{
int n;
for(n=0; n<45;n++) {
printf("%08d %60s EOL\n", n, "");
}
return 0;
}
$ time make x
gcc -Wall -Wmissing-prototypes -fstrict-aliasing -D_GNU_SOURCE -ansi
-ggdb -ggdb x.c -o x
real0m0.076s
$ time ./x>x2
real0m0.301s
so 713ms vs. 377 ms.
Interesting that up to around 100k Perl is even faster:
$ time perl \
-e 'for($n=0;$n<10;$n++) { printf "%08d %60s EOL\n", $n, ""; }' > x
real0m0.167s
$ time make x
real0m0.081s
$ time ./x>x2
real0m0.079s
(of course those figures are far away from being exact; they just prove
how fast perl is: same magnitude as C)
:-)
SCNR.
oki,
Steffen
Re: Building prog first
Steffen Dettmer wrote:
On Mon, Mar 22, 2010 at 4:44 PM, Reuben Thomas wrote:
Not true. automake does not have explicit support for building
programs with the host compiler when cross-compiling, but I
have done this successfully in the past when I needed precisely
to build a program on the host when cross compiling, using
binutils's BFD_CC_FOR_BUILD macro. It's a pity some version of
this macro isn't in autoconf, or even autoconf-archive; I shall
do the latter.
I guess this is a hack and a burden to maintain.
When cross-compiling, why compiling a local tool?
Isn't the correct way to natively compile the local tool,
then use it to cross-compile the package?
This illustrates a weirdness of autotools: poor support for
installing interpreted languages, and also conversely for
build-time compiled programs.
Yes, also for coffee-cooking there is poor support only. :-)
I don't think build-time compiled C programs shall be suppored
while cross compiling. I think it already is complex enough.
Otherwise you had to do all checks twice and end up in many
variables with confusing names, and those who are not
cross-compiling probably accidently will mix them.
I though of perl, but (A), i don't like slow tools,
(I think Perl is fast)
(C), i find making build-programs
in C much more concise than scripting and i can debug it in ddd/gdb.
You can debug Perl in DDD.
This is interesting, as it doesn't match mine or
commonly-reported experience (translating my build-time
programs from C to Perl made them shorter, easier to read and
fix, and no slower to run, although I wasn't doing more than
grepping 15k lines of C and writing some of it back out again).
$ time perl -e \
'for($n=0;$n<45;$n++) { printf "%08d %60s EOL\n", $n, ""; }' > x
real0m0.713s
$ cat x.c
#include
int main(void)
{
int n;
for(n=0; n<45;n++) {
printf("%08d %60s EOL\n", n, "");
}
return 0;
}
$ time make x
gcc -Wall -Wmissing-prototypes -fstrict-aliasing -D_GNU_SOURCE -ansi
-ggdb -ggdb x.c -o x
real0m0.076s
$ time ./x>x2
real0m0.301s
so 713ms vs. 377 ms.
Interesting that up to around 100k Perl is even faster:
$ time perl \
-e 'for($n=0;$n<10;$n++) { printf "%08d %60s EOL\n", $n, ""; }' > x
real0m0.167s
$ time make x
real0m0.081s
$ time ./x>x2
real0m0.079s
(of course those figures are far away from being exact; they just prove
how fast perl is: same magnitude as C)
Hi,
I'd think that printf() in perl would be mapped to the same printf()
in C lib stdio, and because this is the dominant code, the times are
similar.
What i had in mind is the efficiency of regular expression execution
in perl, compared to hard-coded parsing in C.
I will try perl in ddd/gdb some time.
Re: Building prog first
(OT) On Mon, Mar 22, 2010 at 11:50 PM, John Calcote wrote: > Reuben, you've just hit upon one of the two most significant > problems with Javadoc and the like (including doxygen, man > pages, and info pages): sorry, I cannot leave this, because this would be an excuse for people `but we have to use Javadoc, so we cannot document well', which is not true (you said this in your point 2, but I have to stress it :-)). It is not a problem of the tools, but of the documentation. When the main pages in Javadoc and Doxygen documentation are well written, introduce well, include examples and reference important functions, who in turn include example code (often telling more than 1000 words :-)) and again reference functions often needed in this context, this can help really a lot. I think: 1) Someone has to know (learn) the API before starting to use it. (read documentation, make examples) If there is no good documentation and/or no good examples, it would be great to write and contribute :-) 2) Documentation should be written aimed at the target audience. As other software, it must be structured well, easy to read, understand and maintain. Usually it must evolve, first time is always bloody. Also, it should be tested (e.g. reviewed). I think often the problem leading to just have documentation like /** * Uses the passed wizard, which must be a Mage, to do the magic. */ doMagic(Mage wizard); is that people agree that documentation is important but didn't considered well how to do it best. I'm afraid often documentation is considered something `that has to be done also', quickly by the side, instead of considering it as one of the most important parts of the software (it's easy to fix a bug when the documentation clears how it should be, but it's hard to fix documentation when the code behaves oddly). Well, you all know this but I could not resists to write it anyway :) oki, Steffen
Re: Building prog first
On 23 March 2010 06:03, Ralf Wildenhues wrote: > Hello Reuben, > > * Reuben Thomas wrote on Mon, Mar 22, 2010 at 04:44:17PM CET: >> 2010/3/22 Russell Shaw: >> > Steffen Dettmer wrote: >> >> * On Sun, Mar 21, 2010 at 10:27 AM, Ralf Wildenhues wrote: >> >>> BTW, execution of built programs like this makes your package unsuitable >> >>> for cross-compilation. Just so you're aware of that. >> >> Not true. > > Huh? On the level of implementation Russel is working on, that is very > much true. Please read the whole thread; I didn't say this is > impossible. I guess it comes down to what you meant by "like this". I re-read the thread and it seems that Russell is trying to do a very similar thing to what I used to do in GNU Zile, so I'm not sure what about it makes cross-compilation fail, except some small details that he could fix. > Why not go for Autoconf? That is where it should belong, and yes, > better support for this situation would be very nice to have integrated > better. Mostly lack of motivation: this is not a feature I use at the moment. I will do the cleanup required to get the code into autoconf-archive, and someone with more motivation will hopefully "promote" it later. > Hey, as they say, patches welcome! When I have finished rewriting GNU Zile in Lua, I suspect I will want to help with this. -- http://rrt.sc3d.org
Re: Building prog first
On 23 March 2010 10:15, Steffen Dettmer wrote: >> This illustrates a weirdness of autotools: poor support for >> installing interpreted languages, and also conversely for >> build-time compiled programs. > > Yes, also for coffee-cooking there is poor support only. :-) Sure, but autotools is for building programs, not for making coffee. > I don't think build-time compiled C programs shall be suppored > while cross compiling. I think it already is complex enough. > Otherwise you had to do all checks twice and end up in many > variables with confusing names, and those who are not > cross-compiling probably accidently will mix them. On the contrary, this is a very useful feature (why should one not be able to build host programs when cross-compiling?) for which support in autoconf would simplify developers' life (even the ad-hoc support in binutils that I mentioned is pretty easy to use). >> > I though of perl, but (A), i don't like slow tools, > > (I think Perl is fast) Me too, the above assertion was not written by me! You missed the author line at the top from the original author of these double-quoted comments. -- http://rrt.sc3d.org
Re: Building prog first
2010/3/22 Alfred M. Szmidt : > If searching is the problem *Web* searching is the answer, not the problem. It isn't when you are not connected to a network. > how does the indices not fix the problem? I rarely find anything useful in the indices other than particular functions or variables. Rarely, in GNU manuals, concepts, but that is because they do not, on the whole, have good general indices. Do you have a list of such manuals? Would you like to report this to the relevant maintainers? One cannot improve what one does not know about. > What about using a info browser to search through the manual? I often do that. The trouble is that often what I want to know has to be deduced from the manual, which is natural enough, because the manual tends to be structured according to the structure of the program it documents, rather than of the problems the user is trying to solve. By using web searches I can often find people asking and answering precisely the problem I'm trying to solve. Would youlike to suggest a better structuring for some manuals?
Re: Building prog first
On 23 March 2010 17:15, Alfred M. Szmidt wrote: > > 2010/3/22 Alfred M. Szmidt : > > If searching is the problem > > *Web* searching is the answer, not the problem. > > It isn't when you are not connected to a network. I usually wait until I am; it often takes me rather longer to answer questions by simply reading the manuals. > I rarely find anything useful in the indices other than particular > functions or variables. Rarely, in GNU manuals, concepts, but that is > because they do not, on the whole, have good general indices. > > Do you have a list of such manuals? No, but it's most of the manuals I've looked at. > Would you like to report this to the relevant maintainers? No, for several reasons: 1. It's fairly obvious that the indices are in general poor (in common, I should add, with those of most books ever printed). 2. Such a general feature request (it's not really a bug report) is not the sort of thing I usually find useful as a maintainer. It's more useful to notice that I see the matter discussed several times. 3. In practice, I'm really not sure that it's the best use of maintainers' time: as I say, I can generally solve these problems by doing web searches, or if not, then posting a question to a mailing list which hopefully generates a good answer that then becomes searchable. I think spreading internet access to those who don't have it is a much more important goal than writing manuals that answer every question, and further, having better indices would only help slightly. > One cannot improve what one does not know about. True. But this problem is an endemic one, so efforts like Project Mallard, which aims to improve all GNOME programs, at least, are more useful than bug reports to specific projects. > Would youlike to suggest a better structuring for some manuals? No: as I've already indicated, I simply don't know enough. In particular: 1. I don't know how to improve the structuring of manuals to answer these questions better. 2. It's unclear to me that changing the structure of manuals would help much. 3. It is almost certain that changing the structure of manuals would make them less useful for other sorts of use, for example, for users wishing to learn about a system comprehensively, or those who wish for a technical reference. In conclusion: a. With web search, this problem is not so bad currently. b. To improve the way documentation is written will require a great deal of research and experimentation. While individual GNU maintainers who feel strongly about that may wish to do this for their particular packages, it seems unwise to me to encourage all maintainers to do "it" when it is unclear what "it" is. Until there is a sense of emerging consensus and best practice, sticking with the status quo seems far better to me: GNU manuals are frequently high quality manuals of what one might call the "classic" kind, and by imitating the best of them one will do far better than by trying to guess what something better but different might be like. It is possible that I gave the wrong impression either about how serious the problem is (even for those without internet access, careful reading and searching of an Info manual will usually find one the answer eventually), and/or that I gave the impression that I know how to fix the problem (I have only the vaguest idea). I'm sorry in either/both cases. -- http://rrt.sc3d.org
Re: Building prog first
You say that the manuals are poor and that it is obvious, but I cannot figure out from your explanation how they are poor. I've looked at a few manuals, glibc, emacs, coreutils, autoconf, and m4, and all of them have good indices, are organised cleanly, etc. Can you mention one or two manuals, and which part of those manuals you find to be inadequate? You mention that web access improves the manuals, how do they do that exactly? If you do a web search, then you will invariable end up at the manual, no? If our manuals are not read and users think that reporting bugs, improving them, is a waste of our time, then it would be better that we remove them, since keeping them updated takes alot of time, more so than actually improving our programs. But users clearly need manuals, as from your experience, and a bad manual is just as much a bug as anything else in our programs. Please don't think that improving a manual is any less of an improvment than adding a very useful feature.
Re: Building prog first
On 23 March 2010 18:12, Alfred M. Szmidt wrote: > You say that the manuals are poor I said that the indices are poor, specifically at indexing concepts rather than just keywords, function names &c., in general. I also said that the manuals in general are excellent. > and that it is obvious, but I cannot > figure out from your explanation how they are poor. I've looked at a > few manuals, glibc, emacs, coreutils, autoconf, and m4, and all of > them have good indices, are organised cleanly, etc. To understand what I mean by a good index, have a look at a book on indexing, or for a more personal take, along with an exemplar, Douglas Hofstadter's "Gödel, Escher, Bach". > Can you mention one or two manuals, and which part of those manuals > you find to be inadequate? The parts I find inadequate are the indices (as I have said repeatedly). I have already cited the indices of the autotools manuals, e.g. those of the autoconf and automake manuals. I've just had another look at them: they have lists of functions, environment variables &c. and each has a general or "concept" index, which lists the above, plus, as far as I can see, a mixture of section headings and the sort of entries that one might put into a glossary, and not the sort of headings that bring out the structure of the subject of the manuals. I also mentioned Emacs's manual, but I see on further investigation that it doesn't (at least in my version, 23.1, have an index). > You mention that web access improves the manuals, how do they do that > exactly? They take me to answers to specific questions. > If you do a web search, then you will invariable end up at > the manual, no? No, normally I end up on a web page or in a mailing list message. > If our manuals are not read and users think that reporting bugs, > improving them, is a waste of our time, then it would be better that > we remove them, since keeping them updated takes alot of time, more so > than actually improving our programs. But users clearly need manuals, > as from your experience, and a bad manual is just as much a bug as > anything else in our programs. I think we're in furious agreement here. > Please don't think that improving a manual is any less of an > improvment than adding a very useful feature. And again! -- http://rrt.sc3d.org
Keeping source directory structure
Hi all, I have been using automake for a while now, however I recently came across an issue i haven't had to worry about before, which is having duplicate named source files under different directory structures producing conflicting object files. Say i have a source directory structure like: /blah/Makefile.am (the makefile we are talking about) /common/map.cpp /linux/map.cpp and the above automake file with a section like: XXX_SOURCES= \ $(abs_top_srcdir)/common/map.cpp \ $(abs_top_srcdir)/linux/map.cpp where abs_top_srcdir is a variable i define in my configure script that is an absolute path to the top_srcdir (to avoid the ..'s) and is used in the sources instead of $(top_srcdir) What i really want is to build all the object files like: /blah/XXX/common/map.o /blah/XXX/linux/map.o but can also handle a less desirable option: /blah/XXX/($abs_top_srcdir)/common/map.o /blah/XXX/($abs_top_srcdir)/linux/map.o Is there any way I can do this with automake? Or is there any plan to support something like this? I am using automake version: 1.11 I have described below what options Ihave tried: The error i get running automake using the first configuration is similar to: blah/Makefile.am: object `XXX-map.$(OBJEXT)' created by `$(top_srcdir)/common/map.cpp' and `$(top_srcdir)/linux/map.cpp' I then looked at the subdir-objects automake option to solve this problem. Using this fails with an error like (this error message comes from the real code not the above simple example, but gives an idea of the error): Makefile:823: /home/bcosta/build/gary/../../dev/SV/Gary/X3f_951_client_restructure/src/packet/.deps/audio_server-serverstat.Po: No such file or directory There is an existing thread about this problem which it seems nothing was done to address it: http://www.mail-archive.com/bug-autom...@gnu.org/msg00779.html So I tried replacing the variable with: XXX_SOURCES= \ ../common/map.cpp \ ../linux/map.cpp This will kind of build, though the location it is putting the object files in is really bad and conflicts with those from other makefiles. I.e. they are going into: /common/map.o /linux/map.o which is no good for my project. Any help you can give would be greatly appreciated. Thanks, Brendon.
