4 ms·

Please don't use autotools, this is a prime example of why you shouldn't use autotools as the whole of autotools within the project is larger than the project,

Please don't use autotools, this is a prime example of why you shouldn't use autotools as the whole of autotools within the project is larger than the project, an alternative is a simple shell configure to check in env. A few other issues that I don't understand is why you made strndiff / strdiff, str_repeat, str_split it is the same as strncmp / strcmp, strcpy, strtok you just duplicated libc for some reason.

pedro93 12y ago
The behavior of (strndiff / strdiff) is different from strncmp or strcmp. strn?cmp does not return the offset. they are different functions. and in order to ship this package to deb, deploy to different platform, use autotools to test C features is a requirement. (we used to build the project with cmake before we use autotools)
- nwmcsween 12y ago
  Reading it again strdiff is the same as strspn, but your's doesn't actually handle c strings and reads past null. You can do feature tests yourself without pulling in the whole autotools mess: http://git.musl-libc.org/cgit/musl/tree/configure http://git.musl-libc.org/cgit/musl/tree/configure
  - pedro93 12y ago
    Thanks! that helps!
- shadowmint 12y ago
  Is it still possible to build using cmake? I too reliably avoid libraries that depend on these old bloated tools (although I appreciate its helpful for packaging; the script complexity and lack of portability is undeniably a trade off cost in using automake; the usefulness of this library for me would be for a static embedded use case, where automake is of questionable value)
  - pedro93 12y ago
    well. implementing these feature testing scripts is kinda waste of time. so I rather to pick up autotools, which provides a integrated features. to use it for a static embedded use case, you may write your own build script to compile the library (it's not hard to write one). the cflags are describe in src/Makefile.am and you can use pkg-config to list the flags you need.
- danudey 12y ago
  One thing you might want to consider (or might not) is looking at Mongrel 2. It uses ANSI C and supports a variety of platforms, using only gmake and standard macros. I haven't looked at the code very much myself, but it's a pretty neat accomplishments.
q3k 12y ago
And then package maintainers hate you because they have to patch your shell scripts when building for a non-standard platform or environment. Good job.
- nwmcsween 12y ago
  You do know autotools uses shell scripts as well, you don't need to patch anything if you use posix sh.
  - q3k 12y ago
    You do if your custom shell scripts do not allow some of these not-so-standard features (that autotools and other mature build systems provide): - cross-compiling - extra flags (ie. for hardening) for various commands - non-standard install location - non-standard compiler location - skipping/adding steps (strip/nostrip) ...
    - nwmcsween 12y ago
      Almost all of those are not part of a 'configure' check when you pass cflags, cc, prefix its just passed to make Cross compiler working have no place in a build system.

pedro93 12y ago

The behavior of (strndiff / strdiff) is different from strncmp or strcmp. strn?cmp does not return the offset. they are different functions. and in order to ship this package to deb, deploy to different platform, use autotools to test C features is a requirement. (we used to build the project with cmake before we use autotools)

nwmcsween 12y ago
Reading it again strdiff is the same as strspn, but your's doesn't actually handle c strings and reads past null. You can do feature tests yourself without pulling in the whole autotools mess: http://git.musl-libc.org/cgit/musl/tree/configure http://git.musl-libc.org/cgit/musl/tree/configure
- pedro93 12y ago
  Thanks! that helps!
shadowmint 12y ago
Is it still possible to build using cmake? I too reliably avoid libraries that depend on these old bloated tools (although I appreciate its helpful for packaging; the script complexity and lack of portability is undeniably a trade off cost in using automake; the usefulness of this library for me would be for a static embedded use case, where automake is of questionable value)
- pedro93 12y ago
  well. implementing these feature testing scripts is kinda waste of time. so I rather to pick up autotools, which provides a integrated features. to use it for a static embedded use case, you may write your own build script to compile the library (it's not hard to write one). the cflags are describe in src/Makefile.am and you can use pkg-config to list the flags you need.
danudey 12y ago
One thing you might want to consider (or might not) is looking at Mongrel 2. It uses ANSI C and supports a variety of platforms, using only gmake and standard macros. I haven't looked at the code very much myself, but it's a pretty neat accomplishments.

q3k 12y ago

And then package maintainers hate you because they have to patch your shell scripts when building for a non-standard platform or environment. Good job.

nwmcsween 12y ago
You do know autotools uses shell scripts as well, you don't need to patch anything if you use posix sh.
- q3k 12y ago
  You do if your custom shell scripts do not allow some of these not-so-standard features (that autotools and other mature build systems provide): - cross-compiling - extra flags (ie. for hardening) for various commands - non-standard install location - non-standard compiler location - skipping/adding steps (strip/nostrip) ...
  - nwmcsween 12y ago
    Almost all of those are not part of a 'configure' check when you pass cflags, cc, prefix its just passed to make Cross compiler working have no place in a build system.