On Sun, 1 Oct 2023 at 04:45, Jan Engelhardt wrote:
> >I didn't explain sufficiently. The submakes I'm talking about are my
> >doing, and I want to conditionalize them on whether
> >--enable-dependency-tracking is used.
> >
> >In for example both n
>I didn't explain sufficiently. The submakes I'm talking about are my
>doing, and I want to conditionalize them on whether
>--enable-dependency-tracking is used.
>
>In for example both ntpq/Makefile.am and ntpd/Makefile.am I'm invoking:
>
>(cd ../libntp &&a
On Sun, 1 Oct 2023 at 00:59, Nick Bowler wrote:
> Suggestion 2) All explicit --enable-foo/--disable-foo arguments to
> a configure script are available in shell variables; in the case of
> --disable-dependency-tracking you can do something like this in
> configure.ac:
>
>
= x"no"])
> Note that these approaches are different in the case where dependency
> tracking is disabled because it is not supported by the user's tools,
> rather than by explicit request. This may or may not matter for your
> use case.
Nevermind this last point, these sugges
On 2023-09-29, Dave Hart wrote:
> I'm guessing someone has trod this ground before. I'd appreciate
> pointers to examples of how others have detected
> --disable-dependency-tracking to change their build behavior.
Two suggestions, one relying on Automake internals and one not
e the build is correct. When building the project, this adds a bunch
> >of extra submake invocations which slows down the build. I'd like to omit
> >those when --disable-dependency-tracking is used, to speed one-off builds
> >that are done by end-users and packagers.
>
>
e the build is correct. When building the project, this adds a bunch
>>of extra submake invocations which slows down the build. I'd like to omit
>>those when --disable-dependency-tracking is used, to speed one-off builds
>>that are done by end-users and packagers.
>
> submake
bmake invocations which slows down the build. I'd like to omit
>those when --disable-dependency-tracking is used, to speed one-off builds
>that are done by end-users and packagers.
submake is pretty much independent of and from dependency tracking.
The general direction contemporary
omit
those when --disable-dependency-tracking is used, to speed one-off builds
that are done by end-users and packagers.
I'm guessing someone has trod this ground before. I'd appreciate pointers
to examples of how others have detected --disable-dependency-tracking to
change their build
Can I actually rely on Automake making a verbatim
copy of the include line from Makefile.am to Makefile.im?
As far as I can make out, your logic is exactly correct. Looking at
the bin/automake script, I see:
my $PATH_PATTERN = '(\w|[+/.-])+';
# This will pass through anything not of the p
On 2022-11-22 18:32 -0700, Karl Berry wrote:
> Hi Hans - first, congratulations on getting this to work at all.
Thank you for your kind and thorough reply.
> I don't recall anyone else undertaking this.
And that might be why I could not find anybody else doing auto
dependency
Hi Hans - first, congratulations on getting this to work at all.
I don't recall anyone else undertaking this. I'm afraid I don't have any
particular insights, but just so you know someone read your mail:
Question: Is it OK for me to hook into ./$(DEPDIR)/ at all?
I could use
I have not found any documentation about hooking recipes with custom
(non-depcomp) tools into Automake's automatic dependency tracking,
so this describes what I have done to achieve that along with a few
questions.
If you want the complete code example, see the git branch at
https://githu
On Thu, Feb 13, 2020 at 6:40 PM Karl Berry wrote:
> Looking at the automake-patches that have accumulated, I saw one to
> improve the error message if dependency tracking fails. Copied below.
>
> It seems generally sensible to me, though I would change the wording a
> little,
Looking at the automake-patches that have accumulated, I saw one to
improve the error message if dependency tracking fails. Copied below.
It seems generally sensible to me, though I would change the wording a
little, and there is a spurious "the", so, revising the proposed text:
AC_M
stand that.
>
> I'd be OK with that. Do you have one in mind, or do we need to write it
> from scratch? Surely somebody else has solved this problem before.
>
[begin shameless plug]
Have you taken a look at the 'depcomp' script that comes with Automake?
<http://git.savanna
On Fri, Apr 01, 2011 at 01:22:26PM +0200, thus spake Ralf Wildenhues:
> * Ignacy Gawedzki wrote on Wed, Mar 30, 2011 at 10:13:32AM CEST:
> > On Wed, Mar 30, 2011 at 07:51:40AM +0200, thus spake Ralf Wildenhues:
> > > * Ignacy Gawedzki wrote on Wed, Mar 30, 2011 at 12:03:09AM CEST:
> > > > I suspect
s.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Ensure subdirs for subdir scanners are generated when subdir-objects
+# are used, even when dependency tracking is disabled.
+
+required
On Wed, Mar 30, 2011 at 07:51:40AM +0200, thus spake Ralf Wildenhues:
> Hi Ignacy,
>
> * Ignacy Gawedzki wrote on Wed, Mar 30, 2011 at 12:03:09AM CEST:
> > I suspect I found a bug in automake 1.11.1 .
>
> Yes, you have. Thanks for reporting it!
Shall I post that to bug-autom...@gnu.org then?
>
e subdirectories are not created automatically in
> $(builddir) as expected and I think I have found why. It happens when
> configure is called with --disable-dependency-tracking, as is usually the case
> when called through debhelper.
[...]
> Whereas there is *no* rule of the kind :
>
-dependency-tracking, as is usually the case
when called through debhelper.
In the attached tarball, there is a minimal setup illustrating the problem.
Try to configure and build the project in a separate build directory and you
should be able to observe how automake fails to create $(builddir)/src
, in both cases compilation and linking
will occur with multiple archs but preprocessing will occur with a
simple "gcc -E"
That doesn't mean we should break automake dependency tracking in this
configuration, but it does mean you shouldn't do it when it hurts. ;-)
Sorry, but th
arch ppc64" \
> > CXX="g++ -arch i386 -arch x86_64 -arch ppc -arch ppc64" \
> > CPP="gcc -E" CXXCPP="g++ -E"
> >
> I noticed that when configuring like that automake automagically
> turns off dependency-tracking,
" CXXCPP="g++ -E"
I noticed that when configuring like that automake automagically turns
off dependency-tracking, for good reasons.
However, it is not uncommon that people instead issue
./configure CFLAGS="-arch i386 -arch x86_64 -arch ppc -arch ppc64" \
CXXFLAGS="-arch i
a bigger project) using the Automake
> >> "simple tests" feature.
> >>
> >> I have two problems:
> >> [CUT]
> >> 2) Automatic dependency tracking cannot work in
> >>that directory of the project (indeed, the only
> >&g
* Daily, Jeff A wrote on Fri, Jun 25, 2010 at 08:32:46PM CEST:
> I think if we want dependency tracking as a side-effect, then the user
> must list their sources in a dependent order (which only they would
> know). This is what I've had to do in my projects. The downside is
>
> So one complication with Fortran modules is that we don't know the
> order
> in which we need to compile files for the first time. If you want to
> allow file edits to arbitrarily change where modules are defined in,
> then this is true for rebuilds as well. So module
ler-
or system- internal module.
So one complication with Fortran modules is that we don't know the order
in which we need to compile files for the first time. If you want to
allow file edits to arbitrarily change where modules are defined in,
then this is true for rebuilds as well
* Daily, Jeff A wrote on Thu, Jun 24, 2010 at 04:46:28PM CEST:
> > > Why doesn't automake have dependency tracking for preprocessed
> > > Fortran?
> >
> > Because nobody has implemented it yet.
> Ok, so how does one go about developing this sort of thing for
> > Why doesn't automake have dependency tracking for preprocessed
> Fortran?
>
> Because nobody has implemented it yet.
>
> Well, I guess dependency tracking could be implemented similarly to how
> it is done for C and C++. Using makedepend could be a start, sure
Hello Jeff,
* Daily, Jeff A wrote on Wed, Apr 14, 2010 at 11:36:54PM CEST:
> Why doesn't automake have dependency tracking for preprocessed Fortran?
Because nobody has implemented it yet.
> Wouldn't the following work? Note that there is a space before
> include so th
Hello Xochitl,
* Xochitl Lunde wrote on Thu, Apr 22, 2010 at 05:48:20PM CEST:
> I have a problem with my dependency tracking in my auto tools build. I
> have a program like this for an embedded target:
> pald_LDADD = $(am_ldadd)
>
> am_ldadd = \
> -lstartup
> The
I have a problem with my dependency tracking in my auto tools build. I
have a program like this for an embedded target:
-
pald_SOURCES = \
$(top_srcdir)/../common/src/pal/main.cpp
if ac_netos_build
pald_SOURCES+=trippUtils.cpp
# From
Why doesn't automake have dependency tracking for preprocessed Fortran?
Wouldn't the following work? Note that there is a space before include so that
automake doesn't process it, but rather it appears verbatim in the generated
Makefile.in.
F77DEPMODE = makedepend
.F.o:
utomake@gnu.org
Subject: Re: Trying to improve our dependency tracking
Hello James,
* James Willenbring wrote on Thu, May 01, 2008 at 10:51:11PM CEST:
> When I add
>
> myexe_DEPENDENCIES = $(PACKAGEA_DEPENDENCIES)
>
> $(PACKAGEA_DEPENDENCIES) is not resolved before dependencies are
his
problem?
> Does anyone have any suggestions for fixing this problem or for a different
> approach I should take for dependency tracking?
In general, I try to let automake compute dependencies as much as
possible. For example, it cannot "see" the dependency with this:
-- snip lib
Hello,
I am trying to improve dependency tracking for a project I work on. We have
a two level configure process. Under the top configure process we have
about 40 semi-independent packages that have separate configure scripts.
Each package has at least one library archive associated with it
* Jason Kraftcheck wrote on Thu, Jan 18, 2007 at 08:58:13PM CET:
> Ralf Wildenhues wrote:
> > : ${enable_dependency_tracking=yes}
> Why not just
> if test "x$enable_dependency_tracking" = "x"; then
> enable_dependency_tracking=yes
> fi
>
> Is it problematic or non-portable for some rea
Ralf Wildenhues wrote:
> Hello Jason,
>
> * Jason Kraftcheck wrote on Thu, Jan 18, 2007 at 07:39:30PM CET:
>> Is there a way to enable dependency tracking by default even if only slow
>> mechanisms are available (as if --enable-dependency-tracking were always
>> specif
Hello Jason,
* Jason Kraftcheck wrote on Thu, Jan 18, 2007 at 07:39:30PM CET:
> Is there a way to enable dependency tracking by default even if only slow
> mechanisms are available (as if --enable-dependency-tracking were always
> specified?).
You mean as the package develo
Is there a way to enable dependency tracking by default even if only slow
mechanisms are available (as if --enable-dependency-tracking were always
specified?).
thanks,
- jason
On Wed, Oct 11, 2006 at 08:25:07AM +0200, Ralf Wildenhues wrote:
> * Ralf Corsepius wrote on Wed, Oct 11, 2006 at 05:49:00AM CEST:
> > On Tue, 2006-10-10 at 17:55 +0200, Thomas Schwinge wrote:
> > >
> > > What's the deal with making Automake support dependency t
On Wed, 2006-10-11 at 09:55 +0200, Ralf Wildenhues wrote:
> * Ralf Corsepius wrote on Wed, Oct 11, 2006 at 08:52:42AM CEST:
> > OK, I just was about to try automake-CVS + autoconf-2.60 and now am
> > facing an issue with a package using subdir-objects and *_SOURCES
> > containing *.S + *.c:
> >
>
* Ralf Corsepius wrote on Wed, Oct 11, 2006 at 08:52:42AM CEST:
> OK, I just was about to try automake-CVS + autoconf-2.60 and now am
> facing an issue with a package using subdir-objects and *_SOURCES
> containing *.S + *.c:
>
> # autoreconf -Wall
[...]
> /opt/gnu/share/automake-1.9c/am/depend2.a
ou were right though, sorry about that. Dependency tracking is
> implemented in 1.9b. There is however an open issue wrt.
> subdir-objects. Sorry about that.
OK, I just was about to try automake-CVS + autoconf-2.60 and now am
facing an issue with a package using subdir-objects and *_SOURCES
containing
Hello Ralf,
* Ralf Corsepius wrote on Wed, Oct 11, 2006 at 08:28:45AM CEST:
>
> I know it's not implemented in automake-1.8/1.9, but I thought
> this was fixed in HEAD;)
You were right though, sorry about that. Dependency tracking is
implemented in 1.9b. There is however an
On Wed, 2006-10-11 at 08:25 +0200, Ralf Wildenhues wrote:
> * Ralf Corsepius wrote on Wed, Oct 11, 2006 at 05:49:00AM CEST:
> > On Tue, 2006-10-10 at 17:55 +0200, Thomas Schwinge wrote:
> > >
> > > What's the deal with making Automake support dependency t
* Ralf Corsepius wrote on Wed, Oct 11, 2006 at 05:49:00AM CEST:
> On Tue, 2006-10-10 at 17:55 +0200, Thomas Schwinge wrote:
> >
> > What's the deal with making Automake support dependency tracking for (pre
> > processed) Assembler files (the .S ones)? I've seen som
On Tue, 2006-10-10 at 17:55 +0200, Thomas Schwinge wrote:
> Hello!
>
> What's the deal with making Automake support dependency tracking for (pre
> processed) Assembler files (the .S ones)? I've seen some bits of
> discussions about this in various places, but no final
Hello!
What's the deal with making Automake support dependency tracking for (pre
processed) Assembler files (the .S ones)? I've seen some bits of
discussions about this in various places, but no final conclusion so far.
Regards,
Thomas
signature.asc
Description: Digital signature
hi :)
On Fri, Sep 24, 2004 at 05:51:40PM +0200, Alexandre Duret-Lutz wrote:
> The only think holding this patch is that it adds a new language
> without documenting it.
I merged Ralfs and my patch and also added a minimal bit of
documentation:
Index: automake.in
>>> "Martin" == Martin Waitz <[EMAIL PROTECTED]> writes:
[...]
Martin> And somebody should take a look at other compilers, too.
Speaking of these... does anybody know about some C compiler
that compiles *.s files and does not support both `-c -o' at the
same time? In other words, the `compile'
>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
Ralf> On Wed, 2004-09-22 at 17:06, Martin Waitz wrote:
>> Hi,
>>
>> I'm working on a project which uses assembler files which get
>> preprocessed by the C preprocessor (.S files).
>> automake does not yet keep track of dependencies of
On Fri, 24 Sep 2004, Martin Waitz wrote:
hi :)
On Thu, Sep 23, 2004 at 10:50:19AM -0500, Bob Friesenhahn wrote:
How well does this patch work for filesystems which do not preserve
case in file names?
I guess the patch doesn't change the situation here.
Mixed case filenames on such filesystems have
On Fri, 2004-09-24 at 09:58, Martin Waitz wrote:
> But perhaps you are right and we should not separate handling of .s and .S.
I strongly concur.
*.s and *.S are different beasts.
Filesystems and systems which can not distinguish them, have lost.
But this is not an automake problem, this is desi
hi :)
On Thu, Sep 23, 2004 at 10:50:19AM -0500, Bob Friesenhahn wrote:
> How well does this patch work for filesystems which do not preserve
> case in file names?
I guess the patch doesn't change the situation here.
Mixed case filenames on such filesystems have always been a problem.
This patch
How well does this patch work for filesystems which do not preserve
case in file names? Do we need to support filesystems which don't
preserve case?
Bob
On Wed, 22 Sep 2004, Martin Waitz wrote:
Hi,
I'm working on a project which uses assembler files which get
preprocessed by the C preprocessor
On Wed, 2004-09-22 at 17:06, Martin Waitz wrote:
> Hi,
>
> I'm working on a project which uses assembler files which get
> preprocessed by the C preprocessor (.S files).
> automake does not yet keep track of dependencies of these files.
Reminds me about my patch
http://lists.gnu.org/archive/html/
Hi,
I'm working on a project which uses assembler files which get
preprocessed by the C preprocessor (.S files).
automake does not yet keep track of dependencies of these files.
The patch below fixes that for me.
===
diff -urp a
hi :)
i'm working on a project that includes one .S assembly file.
this file uses some preprocessor macros and includes some header files.
automake seems to treat .s and .S files identically and does not
generate automatic dependencies.
would it be possible to add dependency tracking
I would like to have the option of making dependency tracking default
to "no-dependencies",
unless a --enable-dependency-tracking configuration option is used.
Much like how
how AC_DISABLE_SHARED works to decrease compile time.
trt
--
Thomas R. Treadway
Computer Scientist
Lawrence
piled if any of these files change.
That's the purpose of dependency tracking.
miki> AFAIK, it's not mandatory to mention them during compilation
Huh? We don't do this. dependencies != sources
[...]
--
Alexandre Duret-Lutz
I wrote:
>Is there a way to avoid using the ... [dependency tracking]...
Apologies. It *was* in the F*** manual :-). "AUTOMAKE_OPTIONS =
no-dependencies" in Makefile.am works as advertised.
My other question still stands though - regarding the neccesity/advantage
of calling header
Hi all!
For the protocol, I'm using am-1.7 and ac-2.54.
Is there a way to avoid using the dynamically-generated list of make
subrules (for every seperate object file) and simply have automake generate
a static list inside Makefile.in (that will be later copied into the
project's makefile)?
I (*t
> "Tom" == Tom Lord <[EMAIL PROTECTED]> writes:
Tom> Is there anything known to be non-portable about this technique
Tom> for generating a list of all included files?
Yes.
Tom>cc [-I options] -E
Tom>| sed -e '{
Tom>/^#[[:space:]]\{1,\}[[:digit:]]\{1,\}[[:space:]]\{
Is there anything known to be non-portable about this technique for
generating a list of all included files?
cc [-I options] -E \
| sed -e '{
/^#[[:space:]]\{1,\}[[:digit:]]\{1,\}[[:space:]]\{1,\}"/!d
s/^[^"]*"//
s/"[^
Last night I wrote a history of the automatic dependency schemes used
in Automake. I've checked it in to the Automake web pages. Read it
here, if you're interested:
http://sources.redhat.com/automake/dependencies.html
Teaser: it turns out that every dependency tracking scheme
> "Johannes" == Kremp, Johannes (Extern) <[EMAIL PROTECTED]> writes:
Johannes> sorry for this question, but where can i get cvs automake?
Start at the home page.
http://sources.redhat.com/automake/
Tom
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.
sorry for this question, but where can i get cvs automake?
johannes
>>>>> "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
hi, is there a patch which make it possible to make dependency-tracking with
other compiler than 'gcc'? johannes
## Note it is on purpose we wrote `if %AMDEP%', since:
##
## - if deps are turned off, %AMDEP% is mapped onto FALSE, and therefore
## the `if FALSE' chunk is removed (automake-time conditionals).
##
## - if deps are on, %AMDEP% is mapped onto AMDEP, and therefore
## the `if FALSE' chunk is p
>>>>> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
Robert> The latest CVS Automake works fine for
Robert> --enable-dependency-tracking, but when
Robert> --disable-dependency-tracking is specified it's still choking.
Robert> .cxx.o:
Ro
>>>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> gcc3 very nearly does exactly what automake wants in terms of
Tom> dependency tracking.
Tom> I think that ideally automake should recognize this and avoid
Tom> using depcomp when it discovers
gcc3 very nearly does exactly what automake wants in terms of
dependency tracking.
I think that ideally automake should recognize this and avoid using
depcomp when it discovers that the user is using gcc3. In this
situation instead of invoking depcomp we would just invoke gcc like
depcomp does
T it.
> Robert> * automake.in: (handle_dependencies) Replace @AMDEP_TRUE@ in
> Robert> $output_rules with @_am_dep_true@ so that @AMDEP_TRUE@ isn't
> Robert> substituted away when automake is created by configure.
> Robert> * depend2.am: Add @AMDEP_
T it.
> Robert> * automake.in: (handle_dependencies) Replace @AMDEP_TRUE@ in
> Robert> $output_rules with @_am_dep_true@ so that @AMDEP_TRUE@ isn't
> Robert> substituted away when automake is created by configure.
> Robert> * depend2.am: Add @AMDEP_
in: (handle_dependencies) Replace @AMDEP_TRUE@ in
Robert> $output_rules with @_am_dep_true@ so that @AMDEP_TRUE@ isn't
Robert> substituted away when automake is created by configure.
Robert> * depend2.am: Add @AMDEP_TRUE@ to the beginning of lines for
Robert>
> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
Robert> foreach my $iter (@deplist)
Robert> {
Robert> $output_rules .= (' @_am_include@ @_am_quote@'
Robert> . $iter . '@_am_quote@' . "\n");
Robert> }
Problem:
Makefile.in's created with --include-deps do not allow configure
to turn off dependency tracking. If --disable-dependency-tracking
is specified to configure, the rules for object files are invalid,
causing make to exit without building anything. Also, if a compiler
that doe
Title: RE: PATCH: Fix dependency tracking
Automakers:
I posted the patch to demonstrate the problem rather than
get the exact changes I made incorporated into Automake
(hence no ChangeLog entry). The one thing I'm particularly
suspicious of is how to get automake.in's i
# Guess values for system-dependent variables and create Makefiles.
-# Generated automatically using autoconf version 2.13
-# Copyright (C) 1992, 93, 94, 95, 96 Free Software Foundation, Inc.
+# Generated by Autoconf 2.49f.
Automake uses stock 2.13.
On Apr 23, 2001, Robert Boehne <[EMAIL PROTECTED]> wrote:
> Here is a patch that fixes the problems I've been winging about.
> Part of the problem appears to be that @AMDEP_TRUE@ is
> AC_SUBST'd when automake is generated from automake.in,
> so I add a dummy variable and set it to '@AMDEP_TRUE@'
ux_dir && pwd`/missing"
# Use eval to expand $SHELL
-if eval "$MISSING --run :"; then
+if eval "$MISSING --run true"; then
am_missing_run="$MISSING --run "
else
am_missing_run=
@@ -375,22 +375,11 @@
[AC_ARG_ENABLE(dependency-tracking,
[ --disable
tmpdepfile='$(DEPDIR)/%BASE%.TPlo' @AMDEPBACKSLASH@
@AMDEP_TRUE@ $(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@
endif %AMDEP%
%LTCOMPILE% -c -o %LTOBJ% `test -f %SOURCE% ||
echo'$(srcdir)/'`%SOURCE%
endif %?LIBTOOL%
Shouldn't it? I've taken my inst
OK, here's a bit more info:
In automake.in this code appears:
foreach my $iter (@deplist)
{
$output_rules .= ('@AMDEP_TRUE@@_am_include@ @_am_quote@'
. $iter . '@_am_quote@' . "\n");
}
Which, if it added @AMD
CVS version of aclocal.m4 doesn't match CVS m4/depend.m4,
could that cause a problem?
Robert Boehne wrote:
>
> Hello,
>
> There is a bit of a problem in CVS Automake (Today's) when
> --disable-dependency-tracking is specified to configure.
> If dependency track
on should have `#'s in the beginning
> of the lines containing AMDEPBACKSLASH. This should have been a
> result of the new if/endif AMDEP rules in depend2.am.
>
> However, I see the change that introduced AMDEP as a conditional has
> removed the test for the existence of the depco
his should have been a
result of the new if/endif AMDEP rules in depend2.am.
However, I see the change that introduced AMDEP as a conditional has
removed the test for the existence of the depcomp script. Hmm...
Perhaps this is not necessary, since this very script is used to
choose a dependency t
Hello,
There is a bit of a problem in CVS Automake (Today's) when
--disable-dependency-tracking is specified to configure.
If dependency tracking rules have been added to Makefile.in,
the rules created have @AMDEPBACKSLASH@ at the end of the
lines that tell depcomp the required variables s
Sending configure.in as requested
Tom Tromey wrote:
>>>>>> "Dave" == Dave Brolley <[EMAIL PROTECTED]> writes:
>>>>>
>
> Dave> I have a project which contains a mix of C and C++ sources, and
> Dave> dependency tracking does
>>>>> "Dave" == Dave Brolley <[EMAIL PROTECTED]> writes:
Dave> I have a project which contains a mix of C and C++ sources, and
Dave> dependency tracking does not seem to be enabled. I've attached
Dave> my Makefile.am and Makefile.in for reference.
Hi,
The automake online documentation says, regarding automatic dependency
tracking:
" this mode is enabled by default if any C program or library is
defined in the current directory"
I have a project which contains a mix of C and C++ sources, and
dependency tracking does not
>>>>> "Benoit" == benoit LOOF <[EMAIL PROTECTED]> writes:
Benoit>* i need to generate makefiles that compile my program using cc
Benoit>* automake 1.4 requires gcc to perform Automatic dependency tracking
Benoit> so my question is : how
Hi,
here is my problem :
* i need to generate makefiles that compile my program using cc
* automake 1.4 requires gcc to perform Automatic dependency tracking
so my question is : how to get the benefits of Automatic dependency
tracking, compiling with cc ?
wbr,
Benoit Loof
On Oct 17, 2000, "Paul F. Kunz" <[EMAIL PROTECTED]> wrote:
> Is there a way to allow the gcc developer to use automake dependency
> tracking, while the other developer uses some other system.
Use CVS automake. It's dependency tracking mechanism no longer
I have a project being worked on by two people; both with gmake but
one not using gcc. Is there a way to allow the gcc developer to use
automake dependency tracking, while the other developer uses some
other system. The other developer has gcc (but doesn't use it for
the code), so is
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> We compute dependencies in parallel with the actual
Alexandre> compilation, but we mustn't consider the job done before
Alexandre> both are complete.
Ah! Yes, I overlooked the ` "$@" '. Thanks!
On Oct 16, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> | Hi,
> | this patch implements support for extracting dependency tracking
> | information by using the preprocessor mode of the Microsoft Visual
> | C/C++ compiler.
> Thanks, installed.
> Could someone explai
| Hi,
| this patch implements support for extracting dependency tracking
| information by using the preprocessor mode of the Microsoft Visual
| C/C++ compiler.
Thanks, installed.
Could someone explain to me why we launch it in background and then
just wait for it to complete?
1 - 100 of 127 matches
Mail list logo