Building prog first

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

Re: Building prog first

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:

Re: Building prog first

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

Re: Building prog first

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'.

Re: Building prog first

* 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

Re: Building prog first

* 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 their system

Re: Building prog first

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

Re: Building prog first

* 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 noobs so

Re: Building prog first

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

Re: Building prog first

Have you tried reading `(automake) Autotools Introduction'? It is part of the automake manual.

Re: Building prog first

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

better documentation (was: Building prog first)

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

Re: Public header files

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

Re: Building prog first

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