Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

compiling c++ objects to a mirrored directory structure #162

Open
Oneplus opened this issue Apr 23, 2015 · 4 comments
Open

compiling c++ objects to a mirrored directory structure #162

Oneplus opened this issue Apr 23, 2015 · 4 comments
Milestone

Comments

@Oneplus
Copy link
Contributor

Oneplus commented Apr 23, 2015

This issue is discussed in https://groups.google.com/forum/#!topic/maven-nar/SJOHdss-J-8

nar-maven-plugin compiles c/c++ files into same directory. When compiling files with same basename but under different directories, it gives a Output filename conflict error.

This makes it inconvenient when compiling c/c++ project with tons of same name files. Will it be possible that compiling files into mirrored directory structure to avoid such error, just like scons or CMake does.

@ctrueden
Copy link
Contributor

This would be a great feature. See also this thread about CMake integration, which would yield this feature "for free" (but be lots more work than just fixing the NAR plugin as-is).

@Oneplus
Copy link
Contributor Author

Oneplus commented Apr 24, 2015

@ctrueden Actually, we have our old project using CMake for the jni part and ant for the jar part. However, it's quite messy when we deliver the project. For some msvc user, they may have to use CMake to generate the .vsproject and compile it with visual studio via GUI.

So, my point is that CMake can be a quick and free solution. However, it cannot be a neat solution. Also it's expected that lots more work should be done than just fixing the NAR plugin as-is.

@Oneplus
Copy link
Contributor Author

Oneplus commented Apr 24, 2015

@ctrueden see the same issue and a PR in #141 , but it seems fails the CI test.

@ctrueden
Copy link
Contributor

@Oneplus I think that PR #141 needs substantial work, unfortunately—beyond just commit cleanliness etc., the strategy the branch pursues to solve the problem looks to be too fragile. So I think further thought and work is needed to resolve this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants