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.

Sign up for GitHub

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

Jump to bottom

gperf: conan v2 support #14083

Merged
merged 4 commits into from
Jan 27, 2023
Merged

gperf: conan v2 support #14083

merged 4 commits into from
Jan 27, 2023

Conversation

SpaceIm
Copy link
Contributor

@SpaceIm SpaceIm commented Nov 6, 2022

Specify library name and version: lib/1.0

This is also a good place to share with all of us why you are submitting this PR (specially if it is a new addition to ConanCenter): is it a dependency of other libraries you want to package? Are you the author of the library? Thanks!

  • I've read the guidelines for contributing.
  • I've followed the PEP8 style guides for Python code in the recipes.
  • I've used the latest Conan client version.
  • I've tried at least one configuration locally with the conan-center hook activated.

@conan-center-bot

This comment has been minimized.

Sign in to view
@conan-center-bot

This comment has been minimized.

Sign in to view
@SpaceIm
Copy link
Contributor Author

SpaceIm commented Nov 6, 2022 

/c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/01edd76db8e16db9b38c3cca44ec466a9444c388/src/build-aux/compile cl -nologo -MTd -Zi -Ob0 -Od -FS -D_WIN32_WINNT=_WIN32_WINNT_WIN8 -I/c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/01edd76db8e16db9b38c3cca44ec466a9444c388/src/lib -c /c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/01edd76db8e16db9b38c3cca44ec466a9444c388/src/lib/getopt.c
/c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/01edd76db8e16db9b38c3cca44ec466a9444c388/src/build-aux/compile cl -nologo -MTd -Zi -Ob0 -Od -FS -D_WIN32_WINNT=_WIN32_WINNT_WIN8 -I/c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/01edd76db8e16db9b38c3cca44ec466a9444c388/src/lib -c /c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/01edd76db8e16db9b38c3cca44ec466a9444c388/src/lib/getopt1.c
/c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/01edd76db8e16db9b38c3cca44ec466a9444c388/src/build-aux/compile cl -nologo -MTd -Zi -Ob0 -Od -FS -D_WIN32_WINNT=_WIN32_WINNT_WIN8 -I/c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/01edd76db8e16db9b38c3cca44ec466a9444c388/src/lib -c /c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/01edd76db8e16db9b38c3cca44ec466a9444c388/src/lib/getline.cc
/c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/01edd76db8e16db9b38c3cca44ec466a9444c388/src/build-aux/compile cl -nologo -MTd -Zi -Ob0 -Od -FS -D_WIN32_WINNT=_WIN32_WINNT_WIN8 -I/c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/01edd76db8e16db9b38c3cca44ec466a9444c388/src/lib -c /c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/01edd76db8e16db9b38c3cca44ec466a9444c388/src/lib/hash.cc
getopt.c
getopt1.c
hash.cc
getline.cc
c1xx: fatal error C1083: Cannot open source file: 'C:J:/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/01edd76db8e16db9b38c3cca44ec466a9444c388/src/lib/hash.cc': No such file or directory
c1xx: fatal error C1083: Cannot open source file: 'C:J:/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/01edd76db8e16db9b38c3cca44ec466a9444c388/src/lib/getline.cc': No such file or directory
make[1]: Leaving directory '/c/J/w/prod/BuildSingleReference/.conan/data/gperf/3.1/_/_/build/01edd76db8e16db9b38c3cca44ec466a9444c388/build-debug/lib'

mysteries of compilers...

@conan-center-bot

This comment has been minimized.

Sign in to view
@conan-center-bot

This comment has been minimized.

Sign in to view
@SpaceIm
Copy link
Contributor Author

SpaceIm commented Nov 10, 2022 •
edited
Loading

Seems to be quite similar to error in #13446

@stale
Copy link

stale bot commented Dec 11, 2022

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Dec 11, 2022
@uilianries
Copy link
Member

I just started a new CI build right now.

@stale stale bot removed the stale label Jan 16, 2023
@SpaceIm
Copy link
Contributor Author

SpaceIm commented Jan 16, 2023 •
edited
Loading

Ok thanks. I still don't undestand why C++ files are not found in msvc build, but C files are.

@conan-center-bot

This comment has been minimized.

Sign in to view
@jcar87
Copy link
Contributor

jcar87 commented Jan 16, 2023 •
edited
Loading

These 4 commands seem correct:

/c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/0a420ff5c47119e668867cdb51baff0eca1fdb68/src/build-aux/compile cl -nologo -MT -O2 -Ob2 -FS -DNDEBUG -D_WIN32_WINNT=_WIN32_WINNT_WIN8 -I/c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/0a420ff5c47119e668867cdb51baff0eca1fdb68/src/lib -c /c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/0a420ff5c47119e668867cdb51baff0eca1fdb68/src/lib/getopt.c
/c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/0a420ff5c47119e668867cdb51baff0eca1fdb68/src/build-aux/compile cl -nologo -MT -O2 -Ob2 -FS -DNDEBUG -D_WIN32_WINNT=_WIN32_WINNT_WIN8 -I/c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/0a420ff5c47119e668867cdb51baff0eca1fdb68/src/lib -c /c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/0a420ff5c47119e668867cdb51baff0eca1fdb68/src/lib/getopt1.c
/c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/0a420ff5c47119e668867cdb51baff0eca1fdb68/src/build-aux/compile cl -nologo -MT -O2 -Ob2 -FS -DNDEBUG -D_WIN32_WINNT=_WIN32_WINNT_WIN8 -I/c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/0a420ff5c47119e668867cdb51baff0eca1fdb68/src/lib -c /c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/0a420ff5c47119e668867cdb51baff0eca1fdb68/src/lib/getline.cc
/c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/0a420ff5c47119e668867cdb51baff0eca1fdb68/src/build-aux/compile cl -nologo -MT -O2 -Ob2 -FS -DNDEBUG -D_WIN32_WINNT=_WIN32_WINNT_WIN8 -I/c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/0a420ff5c47119e668867cdb51baff0eca1fdb68/src/lib -c /c/j/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/0a420ff5c47119e668867cdb51baff0eca1fdb68/src/lib/hash.cc

the problem is that wherever the paths for the .cc files get converted to windows formats, the conversion seems wrong, judging by the error from cl.exe referencing this, which is an invalid path:

C:J:/w/prod/buildsinglereference/.conan/data/gperf/3.1/_/_/build/0a420ff5c47119e668867cdb51baff0eca1fdb68/src/lib/getline.cc

I can reproduce this locally. And I run the same commands in order (command prompt + call .bat + msys2 bash + source conanbuild.sh) + make, everything works fine. Will keep testing

@jcar87
Copy link
Contributor

jcar87 commented Jan 17, 2023 •
edited
Loading

The issue is due to an interaction between the compile wrapper and the msys2 shell.
Indeed the compile wrapper has different logic for files with the .cc extension, and already performs the unix->windows path conversion (correctly as far as I can see), and then passes -c -TpC:/path/to/file.cc when invoking cl.exe (/Tp being the C++ mode of cl.exe).
The problem arises when msys2 detects a path in the command line arguments provided to cl.exe and then performs a conversion of its own before invoking the process - it starts converting anything that follows -TpC:, and thinks the path starts at /j/w/... , causing the final invocation to look like -TpC:J:/w/prod/... which is consistent with the errors we see above.

The reason this doesn't fail for .c files is because the compile wrapper doesnt perform path conversions in this instance and the command line argument isn't prepended with anything.
The reason this works currently as the recipe it is in master is because ./configure is called "in-place" in the source directory and all the paths in the makefile are relative, whereas now they are absolute - which causes compile to perform path conversions.

An easy way out is to tell msys2 to NOT perform path conversions for the -Tp argument:

env.define("MSYS2_ARG_CONV_EXCL", "-Tp")

As mentioned in there docs, the logic is not perfect for all cases, and looks like we just stumbled upon one of those cases.

Presumably a space between Tp and the filename, or the compile script leaving the unix path untouched, would have also worked.

@SpaceIm @jcar87
prevent msys2 doing erroneous path conversion
40c9620 
Co-authored-by: Luis Caro Campos <3535649+jcar87@users.noreply.github.com>
@SpaceIm
Copy link
Contributor Author

SpaceIm commented Jan 17, 2023

Thanks @jcar87

The reason this works currently as the recipe it is in master is because ./configure is called "in-place" in the source directory and all the paths in the makefile are relative, whereas now they are absolute - which causes compile to perform path conversions.

Is it possible to "fix" the new Autotools helper to always call configure in-place?

@conan-center-bot
Copy link
Collaborator

Conan v1 pipeline

All green in build 6 (40c9620eb7451eaa3220152664b6a935fc667724):

  • gperf/3.1@:
    All packages built successfully! (All logs)

@SpaceIm
Copy link
Contributor Author

SpaceIm commented Jan 17, 2023

Awesome

@github-actions github-actions bot mentioned this pull request Jan 17, 2023
Open
@jcar87
Copy link
Contributor

jcar87 commented Jan 17, 2023

Thanks @jcar87

The reason this works currently as the recipe it is in master is because ./configure is called "in-place" in the source directory and all the paths in the makefile are relative, whereas now they are absolute - which causes compile to perform path conversions.

Is it possible to "fix" the new Autotools helper to always call configure in-place?

Here @czoido may have better context than me to provide an answer.

As far as I know, out-of-tree builds should work fine with Autotools simply by invoking the configure script in a different cwd than the source folder. An interesting think is that I think the deciding factor in whether or not the paths in the Makefiles end up being relative or absolute lies in "how" we invoke the configure script. The current implementation of autotools.configure() does it by invoking the script in its absolute location, but if it did something like ../src/configure, I suspect that would be enough for paths in the generated Makefiles to be relative. Worth testing!

uilianries
uilianries approved these changes Jan 27, 2023
View reviewed changes
Copy link
Member

@uilianries uilianries left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@conan-center-bot conan-center-bot merged commit 34a876e into conan-io:master Jan 27, 2023
@SpaceIm SpaceIm deleted the gperf-conan-v2 branch January 27, 2023 11:54
StellaSmith pushed a commit to StellaSmith/conan-center-index that referenced this pull request Feb 2, 2023
@SpaceIm @jcar87 @StellaSmith
(conan-io#14083) gperf: conan v2 support
bf7beae 
* conan v2 support

* ensure to build from source folder

* in source build for windows

* prevent msys2 doing erroneous path conversion

Co-authored-by: Luis Caro Campos <3535649+jcar87@users.noreply.github.com>

Co-authored-by: Luis Caro Campos <3535649+jcar87@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jcar87 jcar87 jcar87 left review comments

@uilianries uilianries uilianries approved these changes

@toge toge toge approved these changes

@franramirez688 franramirez688 Awaiting requested review from franramirez688

Assignees

@jcar87 jcar87

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@SpaceIm @conan-center-bot @uilianries @jcar87 @toge