[...]
Sreekant> Secondly, how would I ogranize source code in different
Sreekant> directories and the make files in totally seperate
Sreekant> directories?
Maybe you want a setup similar to the one used in the
PalmOS Emulator sources. (Get the Unix sources here:
http://www.palmos.com/dev/te
i wrote in my 'configure.in': SWITCH=hello
AM_CONDITIONAL(HELLO, test "$SWITCH" =
hello)
and in my 'Makefile.am':if HELLO
...
endif
'automake' told me: automake: src/Mak
hi, is there a patch which make it possible to make dependency-tracking with
other compiler than 'gcc'? johannes
I'm sorry, I'm using the latest CVS. I just updated this morning. I'm
still getting the same error (File format not recognized) with
install-strip. Do I need to refresh any scripts? I deleted install-sh
and ran automake --add-missing --copy, but that didn't fix it either.
Thanks,
Emil
On 19
> "Emil" == Emil Ong <[EMAIL PROTECTED]> writes:
Emil> I'm sorry, I'm using the latest CVS. I just updated this
Emil> morning. I'm still getting the same error (File format not
Emil> recognized) with install-strip.
Ok, there's definitely something wrong here.
But without a test case I don'
> "Johannes" == Kremp, Johannes (Extern) <[EMAIL PROTECTED]> writes:
Johannes> hi, is there a patch which make it possible to make
Johannes> dependency-tracking with other compiler than 'gcc'?
This is one of the major new features in the cvs automake.
Tom
> "Johannes" == Kremp, Johannes (Extern) <[EMAIL PROTECTED]> writes:
What version of automake are you using?
Please include version info in every bug report.
Johannes> and in my 'Makefile.am': if HELLO
Johannes> ...
Johannes>
Ok, sure. I made a directory called am-test and put these files in it:
Makefile.am --
bin_SCRIPTS = myscript
configure.in -
AC_INIT(myscript)
AM_INIT_AUTOMAKE(am-test, 1.0)
AC_OUTPUT(Makefile)
myscript -
#!/bin/sh
echo "Hello, World"
Lately I've been thinking that it was a mistake to introduce
_LTLIBRARIES as a parallel primary to _LIBRARIES. I think we could
just have _LIBRARIES and then base decisions on the extension. This
would also let us use the same mechanism for Java jar and zip files.
This is of course a post-1.5 t
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
Tom> The idea would be to read all the Makefile.am
Tom> at once and then generate a single large Makefile.in.
adl> There is something nice about having one Makefile.am in each
adl> subdirectory, it's that it helps to make selfcontai
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Richard> With separate Makefile.am's in each directory,
Richard> automake should be able to figure the bar/foo out from
Richard> the directory paths. The user shouldn't have to worry
Richard> about what the path to the top-level is
On Jun 19, 2001, Tom Tromey <[EMAIL PROTECTED]> wrote:
>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>>> I was thinking I could create a new `patch' category in the automake
>>> Gnats and ask people to put such patches there as attachments. What
>>> do people think of this?
On Jun 20, 2001, Tom Tromey <[EMAIL PROTECTED]> wrote:
> Lately I've been thinking that it was a mistake to introduce
> _LTLIBRARIES as a parallel primary to _LIBRARIES. I think we could
> just have _LIBRARIES and then base decisions on the extension. This
> would also let us use the same mecha
On Jun 20, 2001, Tom Tromey <[EMAIL PROTECTED]> wrote:
>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Richard> With separate Makefile.am's in each directory,
Richard> automake should be able to figure the bar/foo out from
Richard> the directory paths. The user shouldn't have t
14 matches
Mail list logo
