[option 'subdir-objects' is disabled] warnings in cpputest build process

[Amilendra Kodithuwakku]

Hi,

Executing the build instructions given in the website generate warnings similar to the following.
( Please see the attached file for the whole set )
(Windows 7, Cygwin x64 environment autoreconf version 2.69, automake version 1.14 )
---
cd cpputest_build
autoreconf .. -i
....
Makefile.am:35: warning: source file 'src/CppUTest/CommandLineArguments.cpp' is in a subdirectory,
Makefile.am:35: but option 'subdir-objects' is disabled
---

Adding the following line to Makefile.am stops the warnings, and ../configure also seems to pass.
--
AUTOMAKE_OPTIONS = subdir-objects
---

But the make command gave this error.
---
make
Makefile:1256: src/Platforms/Gcc/.deps/lib_libCppUTest_a-UtestPlatform.Po: No such file or directory
make: *** No rule to make target `src/Platforms/Gcc/.deps/lib_libCppUTest_a-UtestPlatform.Po'. Stop.
---

Investigated a little and there was this inside the src/Platforms directory.
---
src/Platforms/$(CPP_PLATFORM)/.deps/lib_libCppUTest_a-UtestPlatform.Po
---

Seems like the $(CPP_PLATFORM) variable wasn't expanded properly, so looked inside the configure script.
---
    # Find all dependency output files, they are included files with
    # $(DEPDIR) in their names.  We invoke sed twice because it is the
    # simplest approach to changing $(DEPDIR) to its actual value in the
    # expansion.
    for file in `sed -n "
      s/^$am__include $am__quote\(.*(DEPDIR).*\)$am__quote"'$/\1/p' <"$mf" | \
         sed -e 's/\$(DEPDIR)/'"$DEPDIR"'/g'`; do
---

If you replace the final line of the above extracted part(around line 20738 ), with the following line, the build successfully completes.
---
         sed -e 's/\$(DEPDIR)/'"$DEPDIR"'/g' | sed -e 's/\$(CPP_PLATFORM)/'"$CPP_PLATFORM"'/g'`; do
---

My question is, what should I change so that I  the configure script will have the above fix from the start?

[Amilendra Kodithuwakku]

Hi,
Okay, I will answer my own question.
Looks like the file to hack is
----
share/libtool/aclocal.m4
----

Since this is a global file, no idea how the changes will affect my system.
Maybe something can be done by changing the cpputest specific build config files.
I think the maintainers should have a better idea on how to get around this, but will let you know if I find something in the meantime.

Best Regards

[Bas Vodde]

Hi,

Yeah, the aclocal.m4 is a file that is generated and not versioned… so it isn’t really an option to hack that one, right?

Last time I checked whether we can get rid of the warning and concluded that there was a bug in autoconf at the moment.
I didn’t read your original post THAT careful, but it seems you found the same bug as me some time ago :)

For that reason, I had decided to live with the very ugly warning for now and hope that it would be fixed asap. But that is some time ago now :(

If you do find a proper way to work around it, that would be great though. The warnings are annoying…

Bas

> --
> You received this message because you are subscribed to the Google Groups "cpputest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cpputest+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Amilendra Kodithuwakku]

​Hi Bass,

Did some searching and it do seem to be an automake bug.

http://stackoverflow.com/questions/21609580/autotools-build-fails-due-to-subdir-objects-option-in-am-init-automake

The last release of automake was in 2013, so it seems likely to be corrected any time soon.

For the time being, the following does the trick.

../configure --disable-dependency-tracking

As for the warnings, other than hacking the Makefile.am file as I mentioned in my original mail,
as you may already know there is another way to remove them by editing the configure.ac file as below.

---
git diff
diff --git a/configure.ac b/configure.ac
index 4d7f5f1..66805ba 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,7 +1,7 @@

 AC_PREREQ([2.68])
 AC_INIT([CppUTest], [3.7dev], [https://github.com/cpputest/cpputest])
-AM_INIT_AUTOMAKE
+AM_INIT_AUTOMAKE([subdir-objects])
 AC_CONFIG_SRCDIR([src/CppUTest/Utest.cpp])
 AC_CONFIG_HEADERS([config.h])
 AC_CONFIG_FILES([cpputest.pc])
---

Regards

Amilendra

On 2014年12月12日(金) at 14:35 Bas Vodde <ba...@odd-e.com> wrote:

Hi,

Yeah, the aclocal.m4 is a file that is generated and not versioned… so it isn’t really an option to hack that one, right?

Last time I checked whether we can get rid of the warning and concluded that there was a bug in autoconf at the moment.
I didn’t read your original post THAT careful, but it seems you found the same bug as me some time ago :)

For that reason, I had decided to live with the very ugly warning for now and hope that it would be fixed asap. But that is some time ago now :(

If you do find a proper way to work around it, that would be great though. The warnings are annoying…

Bas

> To unsubscribe from this group and stop receiving emails from it, send an email to cpputest+unsubscribe@googlegroups.com.

[Bas Vodde]

Hi,

Sure… but I guess I wouldn’t want to disable dependency tracking, right?

So, having the choice between an error or disable-dependency-tracking or the annoying warnings… I’d chose the warnings :)

They are annoying, but it is better than the other choices :)

Bas

> > To unsubscribe from this group and stop receiving emails from it, send an email to cpputest+u...@googlegroups.com.

[Amilendra Kodithuwakku]

Hi Bas,

Yeah I guess so.

However please tell me one thing. Would it make a difference to an end user, doing a one time build?

From the developer's point of view, disabling dependency tracking will force all files to get built regardless of whether  they have been updated or not, but for the end user, this will not matter right?

Just for my knowledge..

Thanks and regards

Amilendra

--

Amilendra Kodithuwakku

[Bas Vodde]

Hi Amilendra,

Sorry for my late reply.

> Yeah I guess so.
> However please tell me one thing. Would it make a difference to an end user, doing a one time build?

Well, I’m actually not sure how end-users build. My guess is that a lot use the Ubuntu or Homebrew package…

Other than that, they would only build once and then it doesn’t matter. But it would be the end user typing the configure command, right?

> From the developer’s point of view, disabling dependency tracking will force all files to get built regardless of whether they have been updated or not, but for the end user, this will not matter right?

Yes. Though I think (not sure) that it won’t build all, but it won’t be able to figure out the dependencies, so therefore it is likely to build too little.

Thanks,

Bas