-
Notifications
You must be signed in to change notification settings - Fork 173
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
Build system usability and security concerns #114
Comments
I agree! |
Understandable. Honesty, WebUI has changed a lot since the first version v1.0 in November 2020. ASIO to C CMake to Makefile Adding pre-built binaries |
The fact is, if you do any kind of C or C++ development, you already have cmake; make files are really neat, but as of now, the build system gets in the way of development more than it solves problems. For ease of use, we could just leave the cmake defaults as the best for users, and then have some options for developers. For the binaries, they should live in the release section, with a script to get them if you really want to automate the process, but having them in git really opens it up to malicious intentions. As a proof of concept, I made a very opinionated branch in my fork, the intent being to show how clean the repo could be without significant sacrifices in usability. |
I already tested making CMake the only build script, and many people skip trying the WebUI because of it. I strongly recommend adding CMake and more build systems in the future, but we will keep the simple legacy makefiles. Let's make WebUI very flexible for different needs. About the pre-built binaries, you are right. We can altogether remove them. We keep the existing script so anyone can generate the same pre-built binaries format (Organized and compressed) to add them to the GitHub releases section. Thank you for the proposed branch, and yes, you can implement the changes to the main repo after updating the branch to apply those points we just discussed:
|
I which if GitHub had a vote option! |
I prefer basic Makefiles instead of cmake personally. However adding cmake support will be good for persons who uses it. Also i support removing the prebuilt libraries. So i vote for both. |
I have a lot of sympathy for people's frustration with cmake; the reason for this issue is not that I want cmake to be my only build system, so I'm all for keeping the makefiles; but in their current state, the makefiles are too many, redundant, and hard to maintain. How about replacing them with a single makefile? For example, the clang and gcc makefiles could be equal, defaulting to gcc (or clang) if the $CC flag isn't set, and using the $CC flag if it is. The call to the makefile with the non-default compiler would be something like |
I agree, but it's hard to do. Multi-compilers in the makefile are possible, but multi-os support is a nightmare. IF ELSE IF ELSE IF I googled and tested it long time ago for other projects, but not all scripts work in all OS. |
Should be fairly easy. This is how it would work on Linux.
The On my system calling Calling Now the only part missing is OS detection. |
https://stackoverflow.com/questions/714100/os-detecting-makefile; doesn't look bad. The CC variable should also work on windows, but of course the default initialization should be something reasonable for windows (if for some reason it's not automatically filled), the compiler flags should also be filled accordingly. |
AI:
ifeq ($(OS),Windows_NT)
CC ?= MSVC
ifeq ($(CC), GCC)
CC = MinGW
endif
ifeq ($(CC), TCC)
CC = TCC
endif
else
UNAME_S := $(shell uname -s)
ifeq ($(UNAME_S),Linux)
CC ?= GCC
ifeq ($(CC), CLANG)
CC = Clang
endif
ifeq ($(CC), TCC)
CC = TCC
endif
endif
ifeq ($(UNAME_S),Darwin)
CC ?= Clang
ifeq ($(CC), GCC)
CC = GCC
endif
endif
endif
all:
@echo $(CC)
|
Even if this |
ifeq ($(CC), TCC)
CC = TCC
endif This pattern is redundant because it assigns the value The ifeq ($(OS),Windows_NT)
CC ?= MSVC
CFLAGS ?= default flags for msvc
# windows copy; zipping and other commands should be defined
else
UNAME_S := $(shell uname -s)
ifeq ($(UNAME_S),Linux)
CC ?= gcc
endif
ifeq ($(UNAME_S),Darwin)
CC ?= clang
endif
CFLAGS ?= default flags for gcc/clang
# unix copy; zipping and other commands should be defined
endif
all:
@echo $(CC)
Under what circumstances would this not work? By the way, as soon as I get some free time, I will implement the build system starting with the make version. |
If |
Thank you in advance 👍 |
By the way, |
I was already thinking to remove the Linux control and treat it as default case if the OS is not windows nor darwin. In that way it will also work for users on BDS systems since they would default to
I'm not familiar with MSVC's flags and utilities, so I'll do some research on the differences. |
Great idea, that should work 👍
Well, here is the first shock, MSVC uses |
Should we also support msvc in gnumake? Or is nmake enough? It looks like the current system allows the user to call minigw-make with the msvc compiler. In that case, doing it in a single file won't be pretty. |
I don't think we need it, because the MSVC users should use |
I mean, we don't need to support msvc in gnu-make. |
Just pushed the first fully functional makefile that supports Windows minigw, Linux clang and gcc, MacOS. Next on the list is Windows nmake.
The built files will be in the The changes are in the |
Thank you @GiuseppeCesarano, for the update. That's great.
This creates a new folder named |
That was the plan, should work without problems; I will probably install a Windows WM and test it!
I don't really understand what you mean, I've seen that the paths are enclosed in " " on the older makefiles and i can do that in the new file too, but will |
Working on #155 |
The current build system is difficult to use and maintain, it is too decentralized and makes it difficult to apply changes.
Running the
./linux_build
script applies many changes to the repository and it is difficult to figure out which ones should be tracked properly; by the way, with the current build system and the fact that library binaries are included in the repository, it is particularly easy for an attacker to push a build with added malware.I strongly recommend removing previously compiled versions from git tracking because it is unusual and not a safe practice.
As for the build system itself, it should be rewritten to use fewer files and remove duplication, i.e. all clang and gcc files are completely interchangeable except for how the compiler is called.
Redundancy creates problems if, for example, a single flag needs to be changed or added. I experimented with LTO and found that enabling it didn't increase compilation time by much, and the binaries produced were 15% smaller; but setting the flag in each and every file is painful.
Finally, this system is also slow because the files are compiled sequentially.
The solution proposed in #94 is good, but I agree that zig is not that widely used yet, then I don't think there is a good integration for Visual Studio.
A single makefile would be nice but it would not be possible to support windows, I think the only solution would be to use cmake as it is a de facto standard and visual studio has good integration.
The text was updated successfully, but these errors were encountered: