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
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
Hi Jef,
On 3/17/10 8:23 AM, Jef Driesen wrote:
I only need it compiled into my library. The goal is that an
application using my library can report the exact revision of the
library (for diagnostic purpose).
With the solution I outlined in my previous posts, I can already get
the "normal" ve
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
14 matches
Mail list logo
