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: /
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
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'.
* 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
* 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
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 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 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
Have you tried reading `(automake) Autotools Introduction'? It is part
of the automake manual.
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'
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
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
* 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
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
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
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
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 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
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
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
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 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
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
(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
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
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
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 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
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 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
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
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
33 matches
Mail list logo
