search

libtom / libtomcrypt

LibTomCrypt is a fairly comprehensive, modular and portable cryptographic toolkit that provides developers with a vast array of well known published block ciphers, one-way hash functions, chaining modes, pseudo-random number generators, public key cryptography and a plethora of other routines.
https://www.libtom.net
Other
1.56k stars 458 forks source link

Build system #391

Closed sjaeckel closed 1 year ago

sjaeckel commented 6 years ago

I'm asking all of you contributors to your preferences when it comes to replace some of the makefiles with a "real buildsystem"^TM.

I thought about one of the following:

I think we should target to replace all makefiles, but I guess it will be harder to also include a solution for makefile.unix, right?

Please feel free to add your comments or ideas!

I'm just mentioning some of the names whose comments I'd like to see: @buggywhip @fperrad @karel-m @rofl0r @sebastianas @stapelberg @tomstdenis

All the others who're reading this are also very welcome to add their ideas.

Thanks :)

stapelberg commented 6 years ago

I found autotools to be the easiest to work with from both, a Linux distribution packaging perspective, and a cross-compilation perspective. I personally don’t like its implementation at all, but found it to be a solid choice overall for open source projects.

I’d vote for autotools, and specifically against cmake, which I find arcane to use time and time again — it seems to provide no benefits over autotools, and is less widely used, meaning people have a harder time finding help for cmake issues.

rofl0r commented 6 years ago

my personal preference is a hand-written configure script (in pure POSIX sh - not bash!) that follows the GNU conventions (to set prefix, options, and test for properties of the system), whose results are then used by a GNU makefile. but for this project probably autoconf is preferable, or just simply stick to what you have.

ksherlock commented 6 years ago

Maybe I'm the only one, but I would prefer cmake. I'm not going to disagree with the above complaints BUT I will note that it can generate (GNU) makefiles, ninja files, Visual studio projects (Visual Studio 17 has CMake builtin and can use it directly), Xcode projects, or a handful of others. I think there are a handful of oddball architectures you want to support that might not readily have a newer version of CMake; Modern (v 3+) CMake is a lot nicer than the older versions. (Another downside is that the web is full of obsolete advice on CMake).

If you buy into the CMake ecosystem, adding in libtomcrypt is as simple as:

add_subdirectory(libtomcrypt)
...
target_link_libraries(myprogram ... libtomcrypt)

I would like to see a CMakeLists included even if it's not the preferred build system (but that of course requires more maintenance and testing).

rofl0r commented 6 years ago

it can generate (GNU) makefiles

yes, it does that, however the makefiles call back into cmake - it means you need cmake installed on the host you want to build. no way around that.

sebastianas commented 6 years ago

On 2018-05-19 08:20:34 [-0700], Steffen Jaeckel wrote:

I'm asking all of you contributors to your preferences when it comes to replace some of the makefiles with a "real buildsystem"^TM.

is there a problem you try to fix or is just "easier maintenance"?

I thought about one of the following:

  • cmake
  • autotools
  • ... any proposals?

I think we should target to replace all makefiles, but I guess it will be harder to also include a solution for makefile.unix, right?

I would go with autotools for the normal "a build system that works everywhere and I don't want to tweak five makefiles" kind of thing. You don't have a specific requirement, do you? What is your concern regarding `makefile.unix'? It looks like a complete makefile which builds the static .a and it supports setting CFLAGS from commandline. Now I don't know any build system that is capable of something like that*. For each one you prepare a template which then is used by the buildsystem to write a makefile (or something similar) which you can't ship (it has to run on the system it has been created for) nor it acceprts overrides. I don't know if this important since the people on minimal embedded devices usually have to face autotools so they should know how to deal with it :)

Sebastian

karel-m commented 6 years ago

I do not think that the build system is currently our biggest trouble.

Anyway, my opinion for the future:

We should keep the same (similar) build system for both libtomcrypt and libtommath (including the helper.pl approach).

tyzoid commented 6 years ago

Regardless of what you decide, I'd suggest to keep in mind those of use that integrate tomcrypt into our own projects / makefiles.

karel-m commented 6 years ago

FYI: branch pr/autotools contains an autotools attempt (disclaimer: it does not mean that I am interested in implementing and/or maintaining the autotools stuff; quite the opposite is true)

palmerc commented 6 years ago

I already build libtomcrypt and libtommath with cmake for the purposes of cross-compiling dropbear. It isn't a feature-for-feature conversion from the Makefile, but it could be extended. I can clean-up and offer a PR if it is interesting.

Personally, I would not use a Makefile or autotools for anything that matters. Whatever the perceived downsides to cmake, the alternatives are much worse for projects with complexity or cross-platform aspirations, and with cmake you can build with ninja.

ChaoWeiAtGit commented 6 years ago

I am wondering how many people trying to port this lib to a bare-metal environment like some kind of boot on arm or mips cpus. I did port some of features of tomcrypt library to a bare-metal environment on an ARM based SoC. The reason is libtomcrypt is easy enough. If I have an posix based environment, I perfer openssl instead. Openssl is more popular so it's easier to find solutions on internet. If you decide to migrate building system to cmake or other complex one, I hope don't obsolete 'make'.

palmerc commented 6 years ago

Jailbroken iPhone or Android cross-compiling is a case where you want to target ARM processors. There is no reason why Cmake cannot co-exist with makefiles and/or output a Makefile (dependency still on cmake). I personally target cmake generation to ninja for building.

ChaoWeiAtGit commented 6 years ago

Yeah, cmake can generate a makefile with its dependencies automatically, but it's harder to read for human(especially for one who is not familiar with cmake like me). I just hope you can consider various of bare-matel environments. The cases of iPhone(UNIX maybe) and Android(Linux) may not suitable. They are both posix like environment. I mean bare-matel environment is such a environment that even standard c library routines are missing. Like 'malloc' which need a heap allocation, 'printf' which should impliment an output interface. If you want to try bare-matel environment, you can compile and link your programm with( I suppose gcc is used) 1.compile your source files with '-nostdinc -fno-builtin' 2.link your object files with '-nostdlib -fno-builtin' 3.In this case, you should write your own link script, so you may need add '-T YOUR-LINK-SCRIPT-FILE' With these options, you can't even use memset, memcpy, strlen ...... I hope cmake can handle it.

Thanks

rofl0r commented 6 years ago

There is no reason why Cmake cannot co-exist with makefiles

the reason is maintenance cost

There is no reason why Cmake cannot [...] output a Makefile (dependency still on cmake)

cmake-generated makefiles are pretty much useless apart from the use during the cmake-triggered build itself. they don't liberate you from the cmake dependency, nor are they reusable in any other way.

I hope cmake can handle it.

when you use a baremetal toolchain, you usually also use a baremetal libc like newlib. so if the toolchain is properly configured, there should be no reason this won't work with any buildsystem, unless the buildsystem prevents you from supplying your own CC, CFLAGS, ... variables.

palmerc commented 6 years ago

Yes, some complain about the cmake dependency, although a relatively minor problem in the great scheme of things.

ClausKlein commented 3 years ago

What is the status of this issue?

Would it make sense to prepare a PR with cmake build support (modern cmake!)

https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/

rofl0r commented 3 years ago

why is it that cmake church members keep pushing their build system down other people's throats. are you getting paid for this?

palmerc commented 3 years ago

why is it that cmake church members keep pushing their build system down other people's throats. are you getting paid for this?

No, it is not a religion, but given experience with a few different build systems, CMake is practically better. Especially with regards toolchains! There are certainly many things about it that are lacking and sometimes, a Makefile is the right choice for a very specific task, but for most things, I'd rather bang out a build in CMake despite its annoying syntax. I have yet to meet someone that was OMG I [heart] autoconf.

ClausKlein commented 3 years ago

why is it that cmake church members keep pushing their build system down other people's throats. are you getting paid for this?

I use a lot of libraries and it is easy to import them with find_package() and use it with target_link_libraries() if they export there config-package with cmake ...

That simply all!

sjaeckel commented 3 years ago

I'm also not too much of a fan of CMake because of its awkward syntax, but the find_package() etc. arguments as also mentioned by @ClausKlein have been given by so many users as advantage that I would accept it as additional build system. The Makefile based approach will still be the default.

There"s a feature/cmake-support branch which is still lacking auto-update on added/removed source files but which would be otherwise fine to be merged IMO (I would have to have a look at it again before merging but that's the major issue IIRC).

Someone can pick up said branch and add the necessary changes to helper.pl (I don't really have the time to do that and it's no priority for me) :)

rofl0r commented 3 years ago

I have yet to meet someone that was OMG I [heart] autoconf.

(modern cmake!) https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/

let me complement this "modern cmake" article with the "modern autoconf" article i've written a couple weeks ago, for completeness sake: https://sabotage-linux.neocities.org/blog/10/

I use a lot of libraries and it is easy to import them with find_package()

it may indeed be easy, but especially this functionality is cmake's biggest weakness as the design of it is bogus: rather than using a generic approach that always works, cmake uses a different script for every single library, and most of them use an approach that returns absolute paths to those libraries, which makes it impossible to do e.g. a static build. the right approach would be to just compile a testcase with -lz added to the command line if e.g. zlib is desired, and if that fails fall back to pkg-config. i've been recently trying to produce a static build of softether vpn for easy installation inside a container, but sane usage of CFLAGS and LDFLAGS isn't supported by cmake. see this abomination of a build recipe and the quantity of hacks i had to use to work around the design choices of cmake: https://github.com/sabotage-linux/sabotage/blob/master/pkg/softethervpn#L50

// edit: in comparison, for autoconf-based projects, you just add -static to LDFLAGS and everything works automatically (as intended by the designers of compilers and linkers back in the day).

you can learn more about proper use of LDFLAGS etc and how to look for a library in my article "Mastering and designing C/C++ build systems" : https://sabotage-linux.neocities.org/blog/5/

ClausKlein commented 3 years ago

IMHO: autoconf and makefiles are not state of the art

@rofl0r there is no pkg-config on Windows?

palmerc commented 3 years ago

@rofl0r I took a look at your script and at the hackery you're engaging in with sed in the post, I'd say, yes, you're suffering. You want to build the library and dependencies in an install script from source, but you don't like the choices they made so you want to hack your way to victory by modifying them using search and replace. This is a legitimate life choice, although, I might suggest some changes.

CMake is just going to generate a file that Make or Ninja consumes. In your case, you want the software and dependencies built in a very specific (your) way. The solutions in this case might be to fork the project and set(CMAKE_FIND_LIBRARY_SUFFIXES ".a") which obviously only works on systems where '.a' denotes a static library OR modify the projects you depend on to offer STATIC build variants without the sed hackery, build them your way and link to them. You could just build and distribute the binary given this use case. You could move your hacking down into the generated Make or Ninja file instead. You could just embrace the shared libraries. By-the-way this argument was had in the 'issues' at SoftEther VPN and shared dependencies won.

This brings us back round to the original issue - CMake is just a practical way to build compiler and platform independent software. It is especially nice when you want to build cross-compiled software like libraries. You should not be reading, worrying about or modifying Make or Ninja (designed to have its input files generated) based builds. In fact, this was the reason I even mentioned cmake in the first place, because it is so easy to cross-compile for iOS and Android with CMake using toolchain files.

sjaeckel commented 3 years ago

IMHO: autoconf and makefiles are not state of the art

To quote the dude... "well that's just your opinion man" ... and I think we shouldn't discuss opinions here. (this also goes to all the others trying to educate the rest of the superiority of their preferred build system)

there is no X on Windows?

I don't care about windows. Please read up about EEE, take your time to really think about it and then re-evaluate whether you should really care about this abomination of an OS.

palmerc commented 3 years ago

IMHO: autoconf and makefiles are not state of the art

To quote the dude... "well that's just your opinion man" ... and I think we shouldn't discuss opinions here. (this also goes to all the others trying to educate the rest of the superiority of their preferred build system)

@rofl0r did start off with 'the church of CMake' and then proceeded to set up an altar to his own opinion in the comments section. I think that set the tone of the discussion.

I originally mentioned CMake in this thread in 2018, solely because I was building this targeting iOS. Build host macOS, using clang. My goal was to build dropbear and its dependencies. Part of the outcome of the effort was a willingness to offer a CMake build for others to use.

lm8 commented 3 years ago

I use the libtomcrypt makefile in all my builds on various platforms. I even use it on Windows (in place of the makefile.mingw) when I build with MinGW. I set LIBPATH, INCPATH, DATAPATH as needed. On Windows, I have a separate makefile (to create a dll from a static library file, libtomcrypt.a) that I autgenerate and use after I run the standard makefile. I find it very easy to build with just the standard makefile. No extra tools needed beyond GNU make. For me, that's the best solution. If I needed more functionality such as capabilities provided by configure or cmake, I'd personally use CDetect in conjunction with make instead. There was a mention of pkg-config in the thread. There are ports of pkg-config to Windows. However, I prefer pkgconf and use that on most of the systems I build for including Windows and FreeDOS. If you're counting votes, my preference would be to have the project continue to offer a simple makefile that works with make. It requires the least prerequisites and dependencies, so I can easily build libtomcrypt on a wide variety of platforms that may not have some of the other build tools readily available. By the way, I think libtomcrypt is a great library. Thanks for making it so accessible and useful.

CCEP16F commented 2 years ago

I've just figured out, that I already done a functional CMakeList.txt file to build libTomCrypt and tomFastMath. CMakeLists.txt

FileTree

I've tested it on Linux(I don't care about Windows), to integrate in a projest just use: include_directories(tcm_folder/libtomcrypt/src/headers tcm_folder/tomfastmath/src/headers) add_subdirectory(tcm_folder) target_link_libraries(app_name ${any other library that u require} tcm)

hopefully someone find it useful.

Apteryks commented 1 year ago

Seems CMake was chosen based on what's in the development branch. I guess this "issue" can be closed.

sjaeckel commented 1 year ago

Indeed