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

Revert incomplete waf integration. #111

Merged
merged 1 commit into from
Sep 16, 2024

Conversation

dag-erling
Copy link
Collaborator

@dag-erling dag-erling commented Sep 4, 2024

I'm not fundamentally opposed to the idea of replacing GNU autotools, but waf is not the right replacement. We should look into either CMake or Meson instead.

@trushworth
Copy link
Collaborator

The discussion on whether waf is the right tool is likely to be a long and involved one, and better left for later, or at least after the release. I should warn you that I've been using build tools of various sorts since the 1970's so I have lots of "stuff" for the discussion :).

This un-waf(ing) can go ahead for the release, but as of when I left off working on TRE, waf was the only way I had to build on Windows. I haven't caught up far enough yet to find out if you have an alternate way to support Windows or if you want to drop support for it. Would something like moving the waf stuff to the contrib directory together with instructions on how to put it back if someone wants to build for Windows work? Unfortunately it is probably going to take me several days to dig the Win7 and Win10 VMs I was using for TRE out of the dusty archive I have them in so I won't be able to test anything I write in the way of instructions or the Windows builds until Sept 10th or 11th. That will make it pretty tight for the targetted release date.

BTW, I don't think I had ever intended waf to be a replacement build system. (Mind you it was long enough ago that I can't remember the wording I used when I put it in.) I was looking at it as an alternate, primarily because I had run into trouble trying to build multiple variants out of the same source tree and having things left over from earlier variants mess up later builds. Using waf let me keep the source code directory pristine and kept the variants out of each others way.

The reason I wanted to build all the variants was that I wanted to test them, particularly in how they worked with the python extension. You can see that most of the files are actually in the Tools/waf directory or a data directory so they're completely independent of the TRE source code.

Anyway, I'll get back to catching up to you two, and digging out my Windows and Linux VMs so I can at least contribute test results :).

@dag-erling
Copy link
Collaborator Author

The repository contains Visual Studio project files, and autotools should work with Mingw64. I'll try to get this working in GitHub Actions.

Moving waf to a contrib directory would just make it rot even faster.

@trushworth
Copy link
Collaborator

I've used Mingw64, but it was a long time ago so I can't remember details. Aside from the fact that it adds a dependency to TRE on Windows, does it handle the file path diddling or is that cygwin only? agrep wants to know :).

@dag-erling
Copy link
Collaborator Author

#112 updates the MSVC project files and ensures that every push and every pull request is automatically tested on Windows. Does that address your concerns?

@dag-erling dag-erling merged commit 95a0f28 into laurikari:master Sep 16, 2024
2 checks passed
@dag-erling dag-erling deleted the des/unwaf branch September 16, 2024 07:30
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

Successfully merging this pull request may close these issues.

2 participants