Chris A. bitemyapp

Effective Modern CMake

Getting Started

For a brief user-level introduction to CMake, watch C++ Weekly, Episode 78, Intro to CMake by Jason Turner. LLVM’s CMake Primer provides a good high-level introduction to the CMake syntax. Go read it now.

After that, watch Mathieu Ropert’s CppCon 2017 talk Using Modern CMake Patterns to Enforce a Good Modular Design (slides). It provides a thorough explanation of what modern CMake is and why it is so much better than “old school” CMake. The modular design ideas in this talk are based on the book [Large-Scale C++ Software Design](https://www.amazon.de/Large-Scale-Soft

Keybase proof

I hereby claim:

I am bitemyapp on github.
I am bitemyapp (https://keybase.io/bitemyapp) on keybase.
I have a public key whose fingerprint is 81D6 75D8 29F1 8485 FDBD B4E2 5809 8478 C9E4 05E5

To claim this, I am signing this object:

The question of "How do I design my application in Haskell?" comes up a lot. There's a bunch of perspectives and choices, so it makes sense that it's difficult to choose just one. Do I use plain monad transformers, mtl, just pass the parameters manually and use IO for everything, the ReaderT design pattern, free monads, freer monads, some other kind of algebraic effect system?!

The answer is: why not both/all?

Lately, I've been centering on a n application design architecture with roughly three layers:

Layer 1:

newtype AppT m a = AppT { unAppT :: ReaderT YourStuff m a } deriving ............ The ReaderT Design Pattern, essentially. This is what everything gets boiled down to, and what everything eventually gets interpreted in. This type is the backbone of your app. For some components, you carry around some info/state (consider [MonadMetrics](https://hackage

Where you able to produce a binary directly from the Rust build tools that you could submit to the app/play store?

Not quite, but I tried to get as close to that as was reasonably possible. Alas, things ended up a little convoluted.

For iOS, I have a nearly empty Xcode project with a build script that copies my cargo produced executable into the .app that Xcode generates (before Xcode signs it). The build script also uses lipo to merge the executables for each architecture I’m targeting (e.g. armv7 and aarch64 for non-simulator devices) into a single, universal binary.

On top of that, there are various iOS-y things that need to happen before my application’s main method is called. SDL2 provides the Objective-C code that does all of that. In a C or C++ game, SDL2 renames main to SDL_main, and then [inserts its own mai

	{-# language TypeInType, QuantifiedConstraints, ConstraintKinds, RankNTypes, UndecidableInstances, MultiParamTypeClasses, TypeFamilies, KindSignatures #-}

	module QC where

	import Data.Constraint
	import Data.Functor.Contravariant
	import Data.Kind
	import Data.Profunctor

	type C = (Type -> Type) -> (Type -> Type -> Type) -> Constraint

	/*
	JSCmd.elm
	==========

	port module JSCmd exposing (..)


	port focus : String -> Cmd msg

	;SMBDIS.ASM - A COMPREHENSIVE SUPER MARIO BROS. DISASSEMBLY
	;by doppelganger ([email protected])

	;This file is provided for your own use as-is. It will require the character rom data
	;and an iNES file header to get it to work.

	;There are so many people I have to thank for this, that taking all the credit for
	;myself would be an unforgivable act of arrogance. Without their help this would
	;probably not be possible. So I thank all the peeps in the nesdev scene whose insight into
	;the 6502 and the NES helped me learn how it works (you guys know who you are, there's no

	#![cfg_attr(any(target_os = "ios", target_os = "android"), no_main]

	fn main() {
	main2();
	}

	#[cfg(any(target_os = "ios", target_os = "android"))]
	#[no_mangle]
	#[allow(non_snake_case)]
	pub extern "C" fn SDL_main() -> i32 {

	module Transformer where

	import Control.Monad.Reader
	import Control.Monad.Trans

	data Config = Config { filename :: String } deriving (Show)

	c = Config { filename = "a.txt" }

	loadFile :: ReaderT Config IO String