1. 09 Mar, 2017 1 commit
  2. 08 Mar, 2017 1 commit
  3. 02 Dec, 2016 1 commit
  4. 01 Dec, 2016 2 commits
  5. 30 Nov, 2016 2 commits
  6. 28 Apr, 2016 1 commit
  7. 19 Apr, 2016 1 commit
  8. 16 Apr, 2016 2 commits
    • David Johnson's avatar
      gcc 5: work around new default -std=gnu11 inline semantics. · 73332fba
      David Johnson authored
      (Of course, this doesn't really matter right now because the
      non-static functions in mul/mul_of.h isn't exported into libmul.a
      right now.)
      73332fba
    • David Johnson's avatar
      Attempt to use automake 1.11, ugh. · 1ef4d1e1
      David Johnson authored
      automake 1.15 (current Ubuntu default) will fail due to the
      long-lived subdir-objects / _SOURCES bug.
      
      It's nontrivial to work around this in the MUL codebase, since
      the apps build using a C main stub file in a different subdir.
      
      Hence automake-1.11, which is happily still available for newer
      Ubuntus.
      1ef4d1e1
  9. 15 Apr, 2016 1 commit
  10. 14 Jan, 2016 3 commits
  11. 04 Dec, 2015 1 commit
    • David Johnson's avatar
      Add a simple argp-like thing for MUL apps (but it uses getopt). · 41b379f6
      David Johnson authored
      MUL's application skeleton that they like us to use (and that saves
      us work) sucks down all the command-line opts via getopt and doesn't
      expose it to the application.  It also parses options before it
      initializes the application "modules", so we can't supply a new app
      callback to handle the opts.
      
      Thus, we add what is basically a secondary initcall-like thing,
      except this one is a struct of callbacks (including the per-app
      getopt parsing function) and data (like the opts and longopts).  So
      the macros define a section of per-module getopt parsing info
      struct pointers, and before calling getopt, the skeleton main
      expands its opts, longopts, and usage with info from these per-app
      getopt helper info structs.
      
      So it really is like a (very) poor man's argp.
      41b379f6
  12. 14 Nov, 2015 1 commit
    • David Johnson's avatar
      Elide the core config.h conflicts to allow multi-config.h includes. · 5f64d6bb
      David Johnson authored
      Every time you think you've reached a new low with autotools, you're
      wrong.  This is my way to get around the standard installable
      config.h problem.
      
      Basically, MUL wants you to include headers that require config.h,
      but of course things that use MUL have config.h of their own.  So --
      we take the hacky approach and remove the things that will obviously
      conflict and stick them in mul_config_internal.h .  I'm sure my way
      of doing this will be missed if config.status common/mul_config.h is
      ever run to regen mul_config.h, but I can't solve that one right now.
      5f64d6bb
  13. 12 Nov, 2015 6 commits
    • David Johnson's avatar
    • David Johnson's avatar
    • David Johnson's avatar
    • David Johnson's avatar
      Fix CI build file. · 5e4d71c6
      David Johnson authored
      5e4d71c6
    • David Johnson's avatar
      Add Flux gitlab CI yml. · 2740e3c4
      David Johnson authored
      2740e3c4
    • David Johnson's avatar
      Improve the MUL build/inst (glib det, sep obj tree, install all). · 7a6d3919
      David Johnson authored
      I improved the MUL build and install (and application build!)
      in several ways:
      
        * Use pkg-config to detect glib-2.0 .  Sadly, the Makefile.ams
          are not really amenable to easy modification to support the
          resulting flags, so that's why I did what I did.  The whole
          glib include/libs thing should change...
      
        * Support external object tree builds, not just builds in the
          source tree.  Lots of $(top_srcdir) action here... and included
          in that morass are updates of bad things, like linking to
          <path>/.libs/libfoo.a -- ugh -- instead of <path>/libfoo.la --
          because that's how this build was set up, and it kind of wants
          to be that way for some symbol stuff I didn't care to dig into.
          I think it has to do with the way apps are built, and some
          symbol deps that the shared objs have, but like I say, I don't
          care right now.
      
        * Support applications built from the installed version of MUL.
          This means we had to install all the headers, and it means that
          we moved from using config.h to mul_config.h , to minimize
          future chances of config.h collisions, heh.  We also install
          the application source skeleton (that has the application
          main()) in $(prefix)/share/openmul/app_mul_main.c or whatever.
          Works like a charm; no more funky app build foo.
      7a6d3919
  14. 22 Oct, 2015 3 commits
  15. 08 Sep, 2015 1 commit
  16. 05 Sep, 2015 1 commit
  17. 02 Sep, 2015 2 commits
  18. 24 Aug, 2015 1 commit
  19. 14 Jul, 2015 1 commit
  20. 08 Jul, 2015 2 commits
  21. 14 May, 2015 1 commit
  22. 13 May, 2015 1 commit
  23. 06 Mar, 2015 2 commits
  24. 01 Mar, 2015 2 commits