A late hello,
* Robert J. Hansen wrote on Tue, Mar 23, 2010 at 12:12:46AM CET:
> On 3/22/10 6: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):
>
> Agreed -- which is w
On Tue, Mar 23, 2010, Reuben Thomas wrote:
> On 23 March 2010 10:15, Steffen Dettmer wrote:
> > * On Mon, Mar 22, 2010, Reuben Thomas wrote:
> > > * 2010/3/22 Russell Shaw :
> > > > [on this ident level, see at the end]
> > > poor support for installing interpreted languages,
> > > and also conve
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
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, an
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
que
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
function
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 b
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
(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
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
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 compili
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-compilatio
On 3/22/10 6: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):
Agreed -- which is why I think it would be wonderful if there was strong
Autotools support for literate progra
On 3/22/2010 4:34 PM, Reuben Thomas wrote:
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 struc
2010/3/22 Alfred M. Szmidt :
> If searching is the problem
*Web* searching is the answer, not the problem.
> 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
If searching is the problem how does the indices not fix the problem?
What about using a info browser to search through the manual?
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. automake does not have explicit suppor
Steffen Dettmer wrote:
* On Sun, Mar 21, 2010 at 10:27 AM, Ralf Wildenhues wrote:
noinst_PROGRAMS = unimain
unimain_SOURCES = unimain.c
unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt
./unimain$(EXEEXT) $< > $@
BTW, execution of built programs like this makes your pack
On Sun, Mar 21, 2010 at 11:18 AM, Russell Shaw wrote:
> But it is somewhat big, and i had already searched through the
> online one a lot first. It is no wonder it takes noobs so long
> to get productive.
Yes, indeed; and even longer to get it productive correctly.
I think this is no matter of t
* On Sun, Mar 21, 2010 at 10:27 AM, Ralf Wildenhues wrote:
> > noinst_PROGRAMS = unimain
> > unimain_SOURCES = unimain.c
> >
> > unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt
> > ./unimain$(EXEEXT) $< > $@
>
> BTW, execution of built programs like this makes your package
Hi Russell,
On 3/21/2010 6:14 AM, Russell Shaw wrote:
I was limping along for years learning autoconf/make in bits until this
tutorial came out
Autotools: a practitioner's guide to Autoconf, Automake and Libtool
http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake
Hello Reuben,
* Reuben Thomas wrote on Sun, Mar 21, 2010 at 07:32:32PM CET:
> 1. This is not a fault especially of GNU documentation; rather, GNU
> documentation is one of the few places in free and open source
> software where one finds properly written manuals.
Nice to hear!
> 2. I suspect the
On 21 March 2010 11:40, Ralf Wildenhues wrote:
> * Russell Shaw wrote on Sun, Mar 21, 2010 at 11:18:03AM CET:
>> But it is somewhat big, and i had already searched through the online
>> one a lot first. It is no wonder it takes noobs so long to get productive.
>
> I'm not sure how to help that. I
Alfred M. Szmidt wrote:
Have you tried reading `(automake) Autotools Introduction'? It is part
of the automake manual.
Hi,
I printed out all the autotools manuals and have read every page of
them more than once. It was a while ago, so it's easy to forget things.
Searching the online manual isn'
Have you tried reading `(automake) Autotools Introduction'? It is part
of the automake manual.
Ralf Wildenhues wrote:
* Russell Shaw wrote on Sun, Mar 21, 2010 at 11:18:03AM CET:
Ralf Wildenhues wrote:
Use noinst_PROGRAMS instead of bin_PROGRAMS. Be encouraged to read the
fine manual.
But it is somewhat big, and i had already searched through the online
one a lot first. It is no wonder
* Russell Shaw wrote on Sun, Mar 21, 2010 at 11:18:03AM CET:
> Ralf Wildenhues wrote:
> >Use noinst_PROGRAMS instead of bin_PROGRAMS. Be encouraged to read the
> >fine manual.
>
> But it is somewhat big, and i had already searched through the online
> one a lot first. It is no wonder it takes noo
Ralf Wildenhues wrote:
* Russell Shaw wrote on Sun, Mar 21, 2010 at 09:26:44AM CET:
Ralf Wildenhues wrote:
* Russell Shaw wrote on Sun, Mar 21, 2010 at 07:06:00AM CET:
bin_PROGRAMS = unimain
unimain_SOURCES = unimain.c
unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt
* Russell Shaw wrote on Sun, Mar 21, 2010 at 08:16:03AM CET:
> Ralf Wildenhues wrote:
> >Furthermore, please don't hard-code absolute paths like
> > /usr/share/unicode/UnicodeData.txt
> >
> >in your makefiles. Make them configurable by configure. Maybe your
> >users don't have root rights on the
* Russell Shaw wrote on Sun, Mar 21, 2010 at 09:26:44AM CET:
> Ralf Wildenhues wrote:
> >* Russell Shaw wrote on Sun, Mar 21, 2010 at 07:06:00AM CET:
> >> bin_PROGRAMS = unimain
> >> unimain_SOURCES = unimain.c
> >unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt
> >./un
However, "make install" installs unimain into /usr/local/bin
Please refer to the manual, it documents how to do that, and more.
You can try the chapter `(automake) Fine-grained Distribution
Control'.
Ralf Wildenhues wrote:
Hello Russell,
* Russell Shaw wrote on Sun, Mar 21, 2010 at 07:06:00AM CET:
I want the "unimain" program built first, then use it to generate
unidata.tab.c, which is then compiled and linked into librunicode.la
bin_PROGRAMS = unimain
unimain_SOURCES = unimain.c
Ralf Wildenhues wrote:
Hello Russell,
* Russell Shaw wrote on Sun, Mar 21, 2010 at 07:06:00AM CET:
I want the "unimain" program built first, then use it to generate
unidata.tab.c, which is then compiled and linked into librunicode.la
bin_PROGRAMS = unimain
unimain_SOURCES = unimain.c
Hello Russell,
* Russell Shaw wrote on Sun, Mar 21, 2010 at 07:06:00AM CET:
> I want the "unimain" program built first, then use it to generate
> unidata.tab.c, which is then compiled and linked into librunicode.la
>
> bin_PROGRAMS = unimain
> unimain_SOURCES = unimain.c
> unidata.tab.c: /
Hi,
I want the "unimain" program built first, then use it to generate
unidata.tab.c, which is then compiled and linked into librunicode.la
bin_PROGRAMS = unimain
unimain_SOURCES = unimain.c
lib_LTLIBRARIES = librunicode.la
librunicode_la_SOURCES = runicode.c runicode.h
#nodist_librun
35 matches
Mail list logo