Slashdot Mirror

← Back to Stories (view on slashdot.org)

Announcing 'build', Auto-Configuration In 1000 Lines Of Makefile (github.com)

Posted by EditorDavid on from the making-build dept.

Christophe de Dinechin created the XL programming language -- and as descubes he's also Slashdot reader #35,093. Today he shares his latest project, a simple makefile-based build system that he's split from ELFE/XL: Most open-source projects use tools such as autoconf and automake. For C and C++ projects, build is a make-based alternative that offers auto-configuration, build logs, colorization, testing and install targets, in about 1000 lines of makefile. A sample makefile looks like this:

BUILD=./
SOURCES=hello.cpp
PRODUCTS=hello.exe
CONFIG= <stdio.h> <iostream> clearenv libm
TESTS=product
include $(BUILD)rules.mk


103 comments

  1. Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 5, Insightful
    The C and C++ world does not need another build system, it needs dependency management systems! It needs tools like https://conan.io/, tools where you can specify what libraries you need independent of what is installed on the host system. Essentially, we need a system like Maven but for native code.

    Multiple versions locally that don't conflict (so .deb doesn't cut it), control over C++ ABI and build type, transitive dependency closure, the works. Work on that, not another damn build system!

    1. Re:Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 0

      this

    2. Re:Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 0

      >Multiple versions locally that don't conflict (so .deb doesn't cut it), control over C++ ABI and build type, transitive dependency closure, the works. Work on that, not another damn build system!

      Yeah, I agree. He hasn't even understood the problem we have. Reproducible builds and dependency management is what we need.

      Guix solves all that. *That's* how this is supposed to be done.

      Also, automake isn't difficult for its own sake, it's because it tries to ensure portability - and portability to potentially hostile competitors is hard. You think they are gonna have a compatible "make"? No, they are gonna break it *on purpose* if they have to. Sheesh.

      Also, from a technical standpoint, he generates a C source file each with one include and then tries to compile that. That takes forever. Why not put all required headers into one C source file and try to compile that? It's much faster and if they are all required anyway there's no downside. Autoconf got it wrong (it also generates a gazillion tiny C source files) and now, many years later, this new thing does it wrong again? *shakes head*

    3. Re: Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 1

      We have that, it's called Docker.

    4. Re:Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 0

      but... but... colorization

    5. Re:Wrong tool! Focus on what we need! by Chris+Mattern · · Score: 4, Funny

      but... but... colorization

      The code is closer to the original artistic vision when it's left in the original black and white.

    6. Re: Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 1

      That would be a nice project for Pottering...

    7. Re:Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 0

      The code is closer to the original artistic vision when it's left in the original black and GREEN.

      FTFY

    8. Re:Wrong tool! Focus on what we need! by UnknownSoldier · · Score: 1

      > it needs dependency management

      I would argue it first needs modules (PDF) modules (2016 CPPcon), something that Pascal solved 29 years ago

      > Multiple versions locally that don't conflict

      That would be a god send if it was standardized across platforms: Win, Linux, OSX. Gee, how did *nix solve this problem? :-)

      >control over C++ ABI

      Agreed. Except the retarded C++ committee doesn't think this is important. Every C++ compiler can call C code generated by ANY compiler but you MUST only call a .lib compiled with the SAME compiler. It is utterly stupid that in 2017 there is STILL no support for an Application Binary Interface.

    9. Re:Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 0

      Unless the author created it with colorization that is.

    10. Re:Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 1

      What we need is fewer dependencies.

    11. Re:Wrong tool! Focus on what we need! by Jherico · · Score: 1

      CMake + Github is about as close as we have in C++ to Maven. Its still pretty ugly though, because C++ doesn't have a consistent build system and the number of options for building and linking is at least two orders of magnitude more than you have to deal with in Java.

      --

      Jherico

      What can the average user can do to ensure his security? "Nothing, you're screwed"

    12. Re:Wrong tool! Focus on what we need! by Mike+Sheen · · Score: 1

      The code is closer to the original artistic vision when it's left in the original black and GREEN.

      The code is closer to the original autistic vision when it's left in the original black and GREEN

      FTFY

    13. Re: Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 0

      Use static libraries. Plan9 already solved that problem

    14. Re:Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 0

      Or better, programmers that care enough about the size of their programs to know the difference between build-time and runtime dependencies, so maintainers don't have to guess.

      If you build without a clear plan, you suffer. autotools is proof of that.

    15. Re:Wrong tool! Focus on what we need! by johannesg · · Score: 1

      Is there a list of packages available through Conan somewhere? Or am I misunderstanding the whole concept?

    16. Re:Wrong tool! Focus on what we need! by johannesg · · Score: 3, Interesting

      > Multiple versions locally that don't conflict

      That would be a god send if it was standardized across platforms: Win, Linux, OSX. Gee, how did *nix solve this problem? :-)

      Not? Compile something on one version of Linux, and pray it works on another. Sending a binary to a customer is just about plain impossible, it will never work on their system.

      I'm sure you guys all love the open source thing, and so do I. But my customers aren't that technical; they don't want to hear about compiler instructions, they want to get a binary they can use without worrying about anything... Copying it to the right location on the machine is about the toughest I can ask of them.

      >control over C++ ABI

      Agreed. Except the retarded C++ committee doesn't think this is important. Every C++ compiler can call C code generated by ANY compiler but you MUST only call a .lib compiled with the SAME compiler. It is utterly stupid that in 2017 there is STILL no support for an Application Binary Interface.

      Amen. As well as the stupid insistence that undefined behaviour is just fine and dandy (I understand it can only be avoided at great cost in some situations, but in others it can be trivially removed from the standard. Forget about that though...), as well as thinking that apparently 'switch' could only ever be used for things that could theoretically be implemented through jump tables... It's 2017, why can't I switch on strings or constexpr classes, at least?

    17. Re:Wrong tool! Focus on what we need! by serviscope_minor · · Score: 1

      Agreed. Except the retarded C++ committee doesn't think this is important

      Ah yes, because "I don't understand the problem == your a retard moran".

      very C++ compiler can call C code generated by ANY compiler but you MUST only call a .lib compiled with the SAME compiler. It is utterly stupid that in 2017 there is STILL no support for an Application Binary Interface.

      OK, genius, write a proposal. Here's why it will fail:

      1. Unixy platforms have settled on the Itanium ABI, which makes exceptions zero cost. They're not going to drop zero cost.
      2. Microsoft uses SEH which are slower but allow catching of more things. They're not going to drop backwards compatibility and flexibility.
      3. Why knows what the hell IAR, do. They don't even document their C library formats, so linking to them from even another C compiler isn't even easy.
      4. Have you even heard of Green Hills?

      So now you have your shiny new (and completely non "retarded") proposal, how do you intend getting everyone to adopt it? Here's a free clue: you can't.

      And here's the other thing. The C++ committee isn't "retarded" simply because you don't understand what they do or why. They are experienced and battle hardened. They know full well that they simply can't drive through a change, because they have no power to. And seriously, what's the point in putting effort to a standard that won't even be adopted.

      --
      SJW n. One who posts facts.
    18. Re:Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 0

      Hmm, 'autistic vision' may be more accurate.

    19. Re:Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 0

      you're*

      hard to take anyone seriously that makes such elementary mistakes on a post that aims to be cerebral

    20. Re:Wrong tool! Focus on what we need! by angel'o'sphere · · Score: 1

      Use Ivy, it is the same like maven but does not build the software, it only manages the dependencies.
      Or use gradle.

      Software written in Java/Groovy, does not really care about the source code languages nor the artifacts it manages in the repository nor about the build tools it calls :D Java is your friend, and Groovy is your buddy :D

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    21. Re:Wrong tool! Focus on what we need! by angel'o'sphere · · Score: 1

      The compiler options complexity is irrelevant.
      It can be put into a Maven/Ivy directory structure trivially.
      Instead of only putting libs under repository control, you could do that with *.o files, too.
      And when the compiler (more precisely a frontend to it) figures it can fetch the o file from a repository instead of compiling it, it just copies it (like the original "clea case build system" before IBM bought the name and used it for an revision control/issue tracker system)

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    22. Re:Wrong tool! Focus on what we need! by ChrisMaple · · Score: 1

      s/black and GREEN/holes punched in cards/

      --
      Contribute to civilization: ari.aynrand.org/donate
    23. Re:Wrong tool! Focus on what we need! by serviscope_minor · · Score: 1

      you're

      The joke, you, whoosh etc.

      --
      SJW n. One who posts facts.
    24. Re:Wrong tool! Focus on what we need! by K.+S.+Kyosuke · · Score: 1

      something that Pascal solved 29 years ago

      Surely you mean "what Modula-2 solved 38 years ago"?

      --
      Ezekiel 23:20
    25. Re: Wrong tool! Focus on what we need! by ChrisMaple · · Score: 1

      Using static libraries doesn't solve the build problem. Are you proposing including all libraries in each source package?

      --
      Contribute to civilization: ari.aynrand.org/donate
    26. Re:Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 0

      And Ada.

    27. Re: Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 0

      Boy I feel silly in your place just reading that comment.

    28. Re: Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 0

      We already have dpendency management for building native libs and apps: Gentoo Linux and it's Portage system.

    29. Re:Wrong tool! Focus on what we need! by Greyfox · · Score: 1
      You could just link your binaries statically. That's always where I end up when I'm writing native software.

      Back in the day when there were dozens of different unixes that you had to conform to, I would have said that a better build system would have been nice, but I'm currently working with ffmpeg on OSX and Linux and find that good old-fashioned makefiles more than adequate to build my code. It'd be fine for Java, too, if you didn't need to bring in 8000 separate components when building your system.

      --

      I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

    30. Re: Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 0

      So dont send a binary compiled on a different system then. (You cant do that with other osrs either. 32/64 bit, abi versions...)

      Your customer isnt technical? Compile for him using the same distro then, they are all free anyway. Give him a proper distro package, problem solved.

    31. Re:Wrong tool! Focus on what we need! by dwarfking · · Score: 1

      I remember years back when we used to discuss cross platform capabilities. This was around the time that Java was starting to be taken seriously, so last century.

      There were some attempts at using a DOSBox like "container" to provide a common target, I recall IBM trying to go with Linux from mainframe to PC to provide a virtual host. Today we see that really coming forward with the Docker type containers.

      But there was another approach that was talked about that would use C or C++ as the cross platform tool, but instead of deploying binaries there would be deployed to each target machine a "compiling tool". An application would then be deployed as either source code or pre-processed ASTs and then it would be converted to binary on the local machine as part of the installation process. I don't recall this ever really going anywhere but always seemed like an interesting approach to me.

      The primary issue I see to overcome regarding package management for C or C++ is the difference that in the Java world Maven can simply grab a Jar file and, so long as there are no binary dependencies, for the most part it works.

      In the C/C++ world you can't simply grab an .SO or .DLL and assume it will work because there is no one target environment like a Java virtual machine and the way the library was built might make assumptions about the host system that might not be the same as the one you're targeting.

      So maybe what we need isn't just a Maven for C / C++ but an intelligently combined build and package management capability. A build tool that is configured with all of the intended platform targets, that can then resolve dependencies by either finding similarly configured pre-built libraries or can fetch library source from a repo, configure and build it using the configurations setup for the project. And to support this a consistent repo structure like what Maven uses so the dependency tool can find transitively dependent components easily.

      Ideally the compilers would need to support cross-compilation so working on any platform, Mac, Windows, Linux, etc. could properly generate binaries for the targets. Basically a Maven like capability that can turn around and actually compile the source code if needed.

    32. Re:Wrong tool! Focus on what we need! by UnknownSoldier · · Score: 1

      > The C++ committee isn't "retarded" simply because you don't understand what they do or why. They are experienced and battle hardened.

      BZZZT. Thanks for Playing.

      1. C++ has become such over-engineered bloated crap that even the committee members themselves admit that they only uses a sub-set of it

      2. This is the same committee that officially recognizes iostreams' performance is shit. When a committee member admits "... fixing iostreams which I hate in all its forms." you know something is rotten in Denmark.

      3. The C++ committee is so far out of touch with reality that they wanted to add a 2D graphics API Cairo to the language. /sarcasm Gee, if only we had a cross-platform graphics library that has been around for 20+ years. Oh WAIT, we already do -- let's ignore OpenGL and invent Yet-Another-Standard that no one gives a fuck about.

      4. When are modules coming again???

      5. Bjarne Stroustrup was so far out-of-touch with modern hardware of the L1 cache that he was surprised to learn that doubly linked lists give shitty cache usage.

      Here's a nickel kid, buy yourself a clue.

      > They know full well that they simply can't drive through a change, because they have no power to ...

      It is not fucking rocket science to standardize name mangling per (hardware) platform -- but keep making excuses for your ignorance.

      > ... your a retard moran".

      Pro-Tip: Only a moron misspells "moran"

      Here's another nickel kid -- buy yourself a spelling and grammar checker.

    33. Re: Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 0

      Windows 32 bit SEH uses the teb, 64 bit does not, it is table based and free.

  2. about time by Anonymous Coward · · Score: 0

    I always wondered why we used that ugly collection of bash, perl and duct tape known as configure, autoconf, automake.

    There have many make based systems in the past. but AFAIK, none of them had really tried to obsolete configure.

    1. Re:about time by F.Ultra · · Score: 3, Insightful

      Everyone thinks that automake+autoconf+libtool are horrible so they create their new build tool. Then once their new build tool gets close to having similar functionality that automakte+autoconf+libtool has they often tend to be far more ugly and horrible.

      And it does not help that we have braindead things like i.e Java JNI where there is a jni.h file in a well hidden non-standards location with a jni_md.h in a system dependent subfolder (so you might have .../freebsd/jni_md.h or ../win32/jni_md.h and so on).

      Or why there might be __BYTE_ORDER__, __BYTE_ORDER or plain BYTEORDER (or due to the infinite wisdom of Microsoft, no such thing at all). Or the good ol boys from OpenSSL that thought that instead of having a define for the presence of an algorithm there should be a define for if the algorithm is supported by the version of OpenSSL but disabled by the configuration. Or why not the flameretarded OpenBSD that decided to hardcoded the OpenSSL version as 2.0 in LibreSSL when they forked the 1.0 API from OpenSSL when OpenSSL then changed some of their API in v1.1 so now you cannot check if version

    2. Re:about time by Lisandro · · Score: 1

      Not really. The only saving grace of autotools is that they're fully written on m4, which is either already installed on every *nix system out there or readily available.

      I'm very partial to CMake which does everything autotools does (and more, like creating VS/XCode projects) in a much saner way, but it requires an additional binary to be installed.

    3. Re:about time by F.Ultra · · Score: 2

      CMake to me is way more horrible than automake, i.e tried to add a --pkgconfig-dir option to a CMake build for hours until I found out that CMake caches the initial value and always uses the cached value regardless of what you supply to the "cmake ." step. And trying to make cmake work in say an initial mingw32 install is always fun.

      Of course it's because I'm way more familiar with automake so it's syntax comes naturally to me. Don't really know why my post was modded as troll though. Must be people who have never tried to make a portable JNI or endian build...

    4. Re:about time by Anonymous Coward · · Score: 0

      $ gcc -MM *.c > Makefile

      is good enough for me.

    5. Re: about time by Anonymous Coward · · Score: 0

      Rule #1 of cmake is always wipe out the build directory when working on the build files themselves.

    6. Re:about time by shutdown+-p+now · · Score: 1

      It's hard to come up with something more horribly designed than automake and autoconf. Most other alternatives are better. The only problem is that there are too many of those alternatives, and there isn't a single one that became a de facto replacement standard because of that.

    7. Re:about time by F.Ultra · · Score: 1

      What exactly is it that people find so horrible with automake+autoconf? The Makefile they produce is completely horrible to look at but the configure.ac, Makefile.am and .in files are actually (IMHO) quite straight forward and they have very good docs at i.e https://www.gnu.org/savannah-c...

    8. Re:about time by descubes · · Score: 1

      One thing is that they take forever to run. On a project I currently work on, Spice, autoconf and automake take over 70s, the build takes about 20s. So we are at the point where auto-configuration takes longer than actual compilation.

      --
      -- Did you try Tao3D? http://tao3d.sourceforge.net
    9. Re:about time by F.Ultra · · Score: 1

      Must be lots of tests :), I've noticed that autoconf is slow as a turtle on Windows but I have always thought that to be due to the MinGW filename mangling.

  3. Hmm... by __aaclcg7560 · · Score: 0, Troll

    I'll stick to using Ant for my Python projects.

    1. Re:Hmm... by Anonymous Coward · · Score: 0

      I care because as soon as I heard Fat Creamer uses Python, I deleted all of my Python code and recoded everything in Perl instead. Python is dead to me.

    2. Re:Hmm... by Anonymous Coward · · Score: 0

      Sorry, which part of python requires a "build" tool? It's a fucking scripting language - the only "build" it requires is running the goddamned python interpreter.

    3. Re:Hmm... by __aaclcg7560 · · Score: 1, Troll

      It's a fucking scripting language - the only "build" it requires is running the goddamned python interpreter.

      The ant build script for my static websites generates the static files using Pelican, archives the output directory to a backup folder on the file server, and then transfer the output files to the web hosting server. I just type "ant all" from the command line for everything to get done automatically. Each static website has a build.properties file that has specific settings for the build script to use.

  4. Like MakeXS by ozzee · · Score: 3, Interesting

    I have a similar make based build system called MakeXS. It's used in the Austria C++ project. It has similar features but my plan was to migrate away from make. Now that Google has released bazel I'm thinking of migrating to it instead.

  5. SCons by Anonymous Coward · · Score: 0

    I found SCons about 10 years ago and use it daily. I only use make when I'm on a project that is already using it. Much easier than make and free threading. Because SCons is implemented in python you can do more than make, IMHO.

    1. Re:SCons by __aaclcg7560 · · Score: 1

      Doesn't look like SCons made the transition to Python 3 yet.

    2. Re:SCons by Anonymous Coward · · Score: 0

      Not yet, but soon. Python 2.7 still works fine in the meantime.

    3. Re:SCons by __aaclcg7560 · · Score: 0

      Python 2.7 still works fine in the meantime.

      If you still have Python 2.7 installed. I've been using only Python 3 for the last few years.

    4. Re:SCons by Anonymous Coward · · Score: 0

      Python 3 is a slow bloated mess, so it's perfect for a fatass like you.

    5. Re:SCons by Anonymous Coward · · Score: 0

      It's only fair; you haven't made the transition to Reality 1.0 yet.

    6. Re: SCons by Anonymous Coward · · Score: 0

      Enjoy your AIDS, you faggot.

    7. Re:SCons by __aaclcg7560 · · Score: 1

      Python 3 is a slow bloated mess [...]

      That's funny. Instagram made the transition from Python 2 to Python 3, and got an unexpected performance boost from CPU and memory savings.

    8. Re: SCons by Anonymous Coward · · Score: 0

      I love when people try to prop up one version of python over another. Let me save you a lot of time - they're all garbage baby-tier languages

    9. Re:SCons by Anonymous Coward · · Score: 0

      Creimer, you've got an awful lot of opinions about Python for someone who apparently doesn't know how to run python projects inside a virtualenv.

    10. Re:SCons by __aaclcg7560 · · Score: 1

      Creimer, you've got an awful lot of opinions about Python for someone who apparently doesn't know how to run python projects inside a virtualenv.

      Sorry, grandpa, your bias against Java and Python 3 is showing again.

      https://slashdot.org/comments.pl?sid=10381487&cid=54110393

    11. Re: SCons by Anonymous Coward · · Score: 0

      This is so funny. C and python have serious usability issues that don't exist in Java. C doesn't have maven. Python doesn't have backward compatibility.

    12. Re:SCons by Anonymous Coward · · Score: 0

      But is it still perfect for a fatass like you? Inquiring minds want to know!

    13. Re:SCons by Anonymous Coward · · Score: 0

      Grandpa? *You*'re 47! There are actual grandpas that are younger than you!

    14. Re:SCons by Anonymous Coward · · Score: 0

      Sorry, grandpa, your bias against Java and Python 3 is showing again.

      First, I said fuck-all about Java. Second, the AC you're talking to in that link ain't me, kid. Third, he's mostly right in what he's told you, though.

      It's funny how you don't seem to understand the basics of the technology you're using, while spouting off all over Slashdot with opinions about the technology.

      Using a piece of python 2.7 code is trivially easy - install 2.7, set up a virtualenv for the tool you need to use, and you're done. You can still leave your default set to python3, it's like saying "Oh god, I can't possibly run Korn shell scripts, because I prefer bash!"

      If you're crazy enough to reinvent the wheel poorly, you deserve the pain you're incurring. But good software engineers don't reinvent the wheel without a good reason for it.

    15. Re:SCons by __aaclcg7560 · · Score: 1

      Using a piece of python 2.7 code is trivially easy - install 2.7, set up a virtualenv for the tool you need to use, and you're done.

      Are you planning to use virtualenv for when Python 2.7 comes to an end in 2020?

      https://pythonclock.org/

      If you're crazy enough to reinvent the wheel poorly, you deserve the pain you're incurring.

      That's funny. Instagram made a smooth transition from Python 2 to Python 3.

      https://slashdot.org/submission/7142015/instagram-makes-a-smooth-move-to-python-3

    16. Re:SCons by Anonymous Coward · · Score: 0

      Are you planning to use virtualenv for when Python 2.7 comes to an end in 2020?

      First: python2.7 won't "cease to exist" in 2020. It will no longer be maintained. Code running on 2.7 won't stop working.
      Second: That's nearly 3 years away.
      Third: Most of the popular pypi packages support python 2 and 3.
      Fourth: For those that don't yet support python3, most of those packages either have an alternative package that does, or plans to release an update that works on python 3.
      Fifth: Instead of reinventing the tool you need, use the python 2.7 version while either working with the upstream project to help them build python3 support, or refactoring your own code to use another package that does support python3.

      I'm not saying "don't use python3" - I'm saying "don't reinvent a tool poorly when a python2 version of the tool exists. Work with the upstream project to help them build python3 support, and in the meantime, make use of python 2."

      That's funny. Instagram made a smooth transition from Python 2 to Python 3.

      And if you know anything about their transition, you'll know it's a nearly year long project to refactor their code base, and work with upstream projects to build python3 support for any critical modules. Which is exactly what I'm suggesting you do, you dummy.

    17. Re:SCons by __aaclcg7560 · · Score: 1

      Work with the upstream project to help them build python3 support, and in the meantime, make use of python 2.

      Except that I don't have Python 2 installed because I'm using Python 3 exclusively. That seems to be an issue on Slashdot. I don't get any crap on the Python dev list for using Python 3 exclusively.

    18. Re:SCons by Anonymous Coward · · Score: 0

      Except that I don't have Python 2 installed because I'm using Python 3 exclusively.

      Time to install a complete python2 installation: 10 minutes.
      Time to reinvent every piece of python2 code that hasn't yet been ported to python3: days, weeks, months.
      Utility of your shitty reinvention: nonexistent.
      Participating in the python community and building a reputation for yourself, while helping to move the language forward to python3: priceless.

      I don't get any crap on the Python dev list for using Python 3 exclusively.

      Really? What name do you post with on python-dev? I've never seen your name there that I can recall, and a quick look at the archives doesn't seem to show any activity from anyone with your name, either.

      And I'm pretty sure that if you said, "Hey guys, rather than run python 2, I'm going to only use python3, and just roll a bunch of my own script-kiddie one offs because I don't really care about contributing to this community," they'd give you some crap, and would tell you exactly what I'm telling you now: participate in the community, and stop reinventing things that just need to be ported forward to python3. Use python2 for critical "need it now stuff," and in parallel, contribute code back upstream to get the code compliant with python3.

      Jesus, why does this not seem to penetrate that dense bony plate you call a skull?

    19. Re:SCons by __aaclcg7560 · · Score: 1

      Time to reinvent every piece of python2 code that hasn't yet been ported to python3: days, weeks, months.

      Which piece of Python 2 code am I reinventing?

      I've never seen your name there that I can recall, and a quick look at the archives doesn't seem to show any activity from anyone with your name, either.

      That's because I don't post under creimer.

    20. Re:SCons by Anonymous Coward · · Score: 0

      Which piece of Python 2 code am I reinventing?

      How about the fabric functionality that's native to pelican? You're using ant (poorly, I'm sure) to replicate functionality that's native to the pelican project itself.

      That's because I don't post under creimer.

      Oh, what name have you posted under, then? I'm on python-dev, I'd be interested to see what you've actually posted. Or were you full of shit when you talked about the python devs never giving you shit when you post, because you've never posted?

    21. Re:SCons by __aaclcg7560 · · Score: 1

      How about the fabric functionality that's native to pelican?

      I didn't consider fabric because it required Python 2.7. I've since learned that there is a Python 3 version, which isn't linked from the fabric web page, has two or three GitHub branches and screams not ready for a production environment.

      You're using ant (poorly, I'm sure) to replicate functionality that's native to the pelican project itself.

      I've previously used Ant for PHP projects. It took me 45 minutes to create a single build.xml file and build.properties files for a dozen static websites. As for the fabric file that Pelican installs, it has three times as many lines as the Ant build.xml file that I've created and lacked the zip/rsync functionality that I needed.

      I'm on python-dev, I'd be interested to see what you've actually posted.

      I post as Chris R. to avoid confusion with Chris A.

  6. It would be nice if by Anonymous Coward · · Score: 0

    the "[COMPILE X/Y] z.cpp" could count up on a single line insted of a new line for each file.

    1. Re:It would be nice if by descubes · · Score: 1

      You mean progress instead of scrolling? Interesting idea.

      --
      -- Did you try Tao3D? http://tao3d.sourceforge.net
  7. A weekend project? by Anonymous Coward · · Score: 1

    Why do we care? What makes it any better than that 50 other make alternatives? Is this a sponsored post?

    1. Re: A weekend project? by Anonymous Coward · · Score: 0, Funny

      Because the author is a transgender person, so we have to support him and/or her or the SJWs will take away our computers.

  8. Typos in a FPP? That's Sad and Low Energy! by Anonymous Coward · · Score: 0

    "Descubes"?

    1. Re:Typos in a FPP? That's Sad and Low Energy! by Anonymous Coward · · Score: 0

      "Descubes" is what happens to "deez nuts" when a guy sits on a hard flat chair and his testicles are pressed into cube shapes.

  9. bsd.prog.mk ? by Anonymous Coward · · Score: 0

    Reminds me of this: https://github.com/openbsd/src/tree/master/share/mk

    Which has been around in BSD for ages.

    1. Re:bsd.prog.mk ? by Anonymous Coward · · Score: 0

      Reinventing the wheel is what shitsters do best.

  10. cmake by Anonymous Coward · · Score: 0

    Cmake is pretty simpler and powerful, and works for the major OSs.
    If makefile simplicity *and* portability are your goals, look no further.

    1. Re:cmake by Lisandro · · Score: 2

      This. CMake is damn close to perfect if you want portable builds.

    2. Re:cmake by Anonymous Coward · · Score: 0

      Cmake is pretty simpler and powerful, and works for the major OSs.
      If makefile simplicity *and* portability are your goals, look no further.

      This is kind of like saying that everyone should do anal sex because it works for everyone. DO NOT WANT.

    3. Re:cmake by Anonymous Coward · · Score: 0

      CMake is also the only tool I've managed to consistency and reliability being able to cross compile different projects without resorting to hacks. With autoconf&friends this usually results in a "Fuck you, I've added /usr/include to the search paths, somewhere within these 50000 lines of code I generated for you."

      But CMake does have a few shortcomings. Compiling an intermediate tool with a different compiler isn't possible for example.

    4. Re:CMake by Anonymous Coward · · Score: 0

      Nice sarcasm! (:

      (For people that don't get it: Cmake isn't for end users. It's for library maintainers.)

  11. plurality breaks build systems by Anonymous Coward · · Score: 0

    The reason people keep reinventing build systems is because there are so many disparate languages and builds. Within a limited set of projects it is usually very easy to use a simple make based build. But when people start expecting one solution to solve all project builds, with simplicity at the same time, you end up with the current state of affairs. Lots of solutions promising a miracle, but generally never delivering.

    Complexity generally arises as a result of historical accumulation and erroneous thinking. The world if full of this. Ironically, nearly every new miraculous solution to a complex problem simply compounds rather than solves the problem.

    1. Re:plurality breaks build systems by Bent+Spoke · · Score: 1

      It's sad that 30 years on, none of the existing config/build systems seem to offer even basic debugging capabilities.

      Which is why on the Jsi project (jsish.org), the configure is handled by, well Jsi itself.

      That is, a minimal interpreter is built with just enough language features to perform the configuration.
      No external programs are used. If there is a problem, we can use the Jsi debugger to single step through it.

      Try doing that with m4 (used by autotools), cmake, et al.
      In fact, debugging is not possile when you are using:

      bash
      make
      gcc/g++/ld/ar
      autoconf/automake/libtool
      m4
      awk
      sed
      basename
      chmod/chown
      strip
      grep
      find
      cpp
      gdb
      yacc/bison
      lex/flex
      tar/gzip/zip
      man
      cmake
      lua
      tcl
      perl
      python

  12. BSD Makefiles or automake by manu0601 · · Score: 2

    It looks like BSD Makefiles (sample below)... or just like automake's Makefile.am

    .include <bsd.own.mk>
    WARNS=6

    PROG= sed
    SRCS= compile.c main.c misc.c process.c

    .include <bsd.prog.mk>

    1. Re:BSD Makefiles or automake by descubes · · Score: 1

      Yes, it's intended to be similarly short. Compared to the BSD makefiles, what's new is the configuration step. Compared to automake, it's that it does not require a (lengthy) makefile generation phase to run first.

      There are also drawbacks, obviously. Autoconf and automake are more feature-complete. But for simple projects, it's probably a good choice.

      --
      -- Did you try Tao3D? http://tao3d.sourceforge.net
  13. Wow by Crackerjack · · Score: 2

    I'm slashdot user #15,884 and my make-based autoconfiguration system is at least 3x as long. I could really learn from this guy.

  14. CMake by sshock · · Score: 2

    CMake is easy too.

  15. so this is like cmake. but does less. by Anonymous Coward · · Score: 0

    just use cmake.

  16. XKCD already covered this by Anonymous Coward · · Score: 0

    I'm afraid XKCD described this problem of competing build systems very well, years ago.

    https://xkcd.com/927/

  17. My bazel BUILD file by LagFlag · · Score: 1

    My bazel BUILD file:

    cc_binary(
        name = "HttpEchoServer",
        srcs = ["src/HttpEchoServer.cpp"]
                +glob(["src/common/**/*.cpp"])
                ,
        includes = [],
        copts = ["-g","-std=c++1z","-I/usr/include/mysql++","-I/usr/include/mysql","-Isrc","-Isrc/common"],
        linkopts = ["-L/usr/local/lib",
                    "-lcairo","-lcryptopp","-lpq",
                    "-lPocoCrypto","-lPocoFoundation","-lPocoJSON","-lPocoNet","-lPocoNetSSL","-lPocoUtil",
                    "-lboost_date_time","-lboost_unit_test_framework","-lboost_random","-lboost_system","-lgtest",
                    "-lproxygenhttpserver","-lfolly","-lglog","-lgflags","-lpthread"],
    )

    1. Re:My bazel BUILD file by Orphis · · Score: 1

      When you hardcode paths local to your machine and compiler options specific to your compiler, you can use build tool, it doesn't really matter.

  18. Re:Hooray! by lordlod · · Score: 1

    For what it is worth, which is nothing. Coding has never landed me a job no matter what I do.

    The tech industry can suck the rancid shit out of my old bitter asshole. Fuck you all to hell, you fucking motherfuckers.

    You should try writing decent code, and maybe working on your people skills.

    It is nice of you to warn potential employers off though.

  19. Solving what problem? by Anonymous Coward · · Score: 0

    It looks _more_ complicated than cmake to achieve anything useful with this tool, and it lacks the proper dependency management. Also, I don't want to use make at all. It minimally needs to work with ninja and msbuild instead. I don't really understand what problem this tool is trying to solve.

  20. Reinventing the wheel? Greeting from NetBSD! by hubertf · · Score: 3, Insightful

    BSD based Unix systems have this for along time.
    Both in the base system, and for 3rd party software.

    Base system example:
    http://cvsweb.netbsd.org/bsdwe...

    Then again, there's not much need for "autoconf"-like system environment detection there. The actual build system is also in a lot of Makefile snippets in the share/mk directory:
    http://cvsweb.netbsd.org/bsdwe...

    For 3rd party software that's build from a make-based system, see http://www.pkgsrc.org/

  21. Because what this world needs... by lbalbalba · · Score: 1

    ... is NOT another build system.

  22. GPLv3 license by Anonymous Coward · · Score: 0

    Most other reinventions of the build system wheel suck in various ways, so I don't think it's totally wrong to try reinventing it again. However, attaching a GPL license to your new wheel seriously limits your chance of success. autoconf is very deeply entrenched with the people who view GPL as a feature. IMHO, your best chance of finding users lies among the people who view GPL as a bug, but you're excluded them. Good luck with that.