cannot find dpp/ref, compile failure

[quentin.meunier@…]

At compile time the process fails on finding #include <dpp/ref> in the vci_buffer.h file.

When I change the vci_buffer.h file in order to set a "local dependency" on this file (ie : #inclue "dpp/ref" instead of <dpp/req>) it fails at resolving the dependency as you can see in the attached log file

My revision is the latest one (1406).

[Nicolas Pouillon]

It seems you have the same problem exposed in #30. Please ensure the svn:external is correctly checked-out at trunk/soclib/soclib/lib/dpp/source/include

[quentin.meunier@…]

Soclib was updated from the root right before the operation. We also cleaned everything and deleted the build directory (besides, the author of the ticket #30 reported that he never understood how the problem was solved).

By the way, the file dpp/ref exists, but just isn't found at compile time. Pierre suggested that my tool (or version of the tool) used to check dependancies could have a problem with the name (not finishing with a legal suffix), but this is apparently not the case (I tried to change the name of the file to ref.h, with no more success).

As a last note, when letting the "<" and ">" on the include line, the compilation process goes until 10 elements are left, whereas when changing to double quotes, it fails for the first element (and the make clean also fails in the latter case).

Thanks in advance,

[Nicolas Pouillon]

• could you ensure your subversion client does handle svn:externals ?
• could you ensure a directory listing of soclib/soclib/lib/dpp/source/include/dpp

yields something like:

$ ls ~/projects/soclib/soclib/lib/dpp/source/include/dpp
foreach  interval_set  linked_list  ref
$ 

As dependency calculation is cached, you may have a unpredictable number of objects built before failure.

Also please note header naming convention for c++ is no suffix if the header does not dump everything in the global scope. So yes, <dpp/ref> is a valid header name, the very same way <iostream> is. (iso/cei 14882:1998 - 17.4.1.2)

[quentin.meunier@…]

• could you ensure your subversion client does handle svn:externals ?

The svn used is version 1.5.1, therefore it should handle that.

• could you ensure a directory listing of soclib/soclib/lib/dpp/source/include/dpp

It precisely displays

foreach  interval_set  linked_list  ref

[Nicolas Pouillon]

Could you rerun your compile with --bug-report and attach the whole log ?

Thanks

[quentin.meunier@…]

full bug-report log

[quentin.meunier@…]

No problem the file is attached. I hope the command run was correct.

[Nicolas Pouillon]

Sorry, I forgot to tell… Could you also add -v ?

[quentin.meunier@…]

debug-log with the -v option

[Nicolas Pouillon]

Ok, I got it.

Your VciTargetFsmNlock module uses vci_buffers.h, but does not declare this use in the .sd module definition. Therefore, the build system does not know it has to include dependencies of vci_buffers for building this component.

The fact it worked before was just a side-effect of lazy inclusion paths.

You must add Uses('caba:vci_buffers'), in vci_target_fsm_nlock.sd.

[quentin.meunier@…]

Ok that's it, thank you a lot for your time spent.

Btw, Pierre asks whether there is a way in soclib-cc to enforce a check of all dependancies and avoid this kind of problem. Namely in this case (if I understood correctly), would have it been possible to have an error with the inclusion of vci_buffers.h instead of the given error (i.e., it actually found the file vci_buffers.h because it was included by another component, but not ddp/ref) ?