allow compilation of files with same names

[ruimaranhao]

Enable compilation of files with the same name but different folders.

[buildhive]

NAR plugin for Maven » nar-maven-plugin #278 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[ruimaranhao]

The buildhive failure seems to be a problem not related with the pull request. The output console dumps the following output:

Modules changed, recalculating dependency graph
ERROR: Processing failed due to a bug in the code. Please report this to jenkinsci-users@googlegroups.com
java.lang.NullPointerException
project=hudson.maven.MavenModuleSet@f44809c[maven-nar/nar-maven-plugin]
project.getModules()=[hudson.maven.MavenModule@b05653a[maven-nar/nar-maven-plugin/com.github.maven-nar:nar-maven-plugin][maven-nar/nar-maven-plugin/com.github.maven-nar:nar-maven-plugin][relativePath:], hudson.maven.MavenModule@2d27b987[maven-nar/nar-maven-plugin/org.apache.maven.plugins:maven-nar-plugin][maven-nar/nar-maven-plugin/org.apache.maven.plugins:maven-nar-plugin][relativePath:]]
project.getRootModule()=hudson.maven.MavenModule@b05653a[maven-nar/nar-maven-plugin/com.github.maven-nar:nar-maven-plugin][maven-nar/nar-maven-plugin/com.github.maven-nar:nar-maven-plugin][relativePath:]
FATAL: null
java.lang.NullPointerException

[dscho]

@ruimaranhao First of all: it is great that you contributed to this exciting project. Thank you!

And do not worry about BuildHive; I just ran the integration tests successfully here. Sometimes BuildHive has problems.

However, I would like to request a slight change that will make reviewing this commit much easier. Also, I would like to ask for an additional commit that, say, modifies it0001-executable to include a second Executable.c file, so it is easy to understand which issue this PR addresses, as well as making sure that it gets never broken again.

Lastly, instead of using hashCode() I would prefer keeping things as they are as much as possible. To do that, just use a HashSet<String> to remember the file names that were used already, and modify the output file name only on demand, adding a -<n> suffix with increasing n until no clash was detected.

[buildhive]

NAR plugin for Maven » nar-maven-plugin #279 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[dscho]

This time around, it seems that Jenkins actually picked up on a real problem:

[DEBUG] Execute:Java13CommandLauncher: Executing 'g++' with arguments:
'-Wall'
'-Wno-long-long'
'-Wpointer-arith'
'-Wconversion'
'-fPIC'
'-c'
'-DLinux'
'-DGNU_GCC'
'-I/scratch/jenkins/workspace/maven-nar/nar-maven-plugin/target/it/it0015-cpp-executable/src/main/include'
'/scratch/jenkins/workspace/maven-nar/nar-maven-plugin/target/it/it0015-cpp-executable/src/main/c++/Executable.cpp'
'/scratch/jenkins/workspace/maven-nar/nar-maven-plugin/target/it/it0015-cpp-executable/src/main/c++/example.cxx'
'-o'
'Executable902485904.o'

The ' characters around the executable and arguments are
not part of the command.
[ERROR] g++: fatal error: cannot specify -o with -c, -S or -E with multiple files
[ERROR] compilation terminated.

So I fear that the strategy is not quite working: in order to prevent multiple files with identical file name from clashing, we would need to specify output names, but at the same time, we also need to pass the -c flag...

[ruimaranhao]

gonna check it how to make it work.

Would it be possible to use the program that you're using to test ?

[dscho]

gonna check it how to make it work.

The best strategy is probably to accumulate the paths of the clashing files and call the compiler individually on those, so that -c and -o can be used together. For efficiency, I would keep the default case unchanged, though: calling the compiler only once for as many files as possible...

[dscho]

@ruimaranhao how's it going?

[dproteus13]

I think the error gcc is kicking out is not because you're specifying -o with -c, so much as it's because you're specifying -o with a list of multiple files to compile. The error message is less than clear, but thinking about what you're asking gcc to do makes it pretty clear that it probably won't work... You're compiling two different objects, so they'll each need their own name... But with the -o argument there is no way to provide those names... It seems (to me) like the strategy needs a little refinement here...