This commit is contained in:
wgroeneveld 2018-08-10 09:09:35 +02:00
parent f471d4a89a
commit 3e869d031f
2 changed files with 5 additions and 92 deletions

View File

@ -110,7 +110,7 @@ Look at this well-documented [Google Coding Interview University](https://github
> I originally created this as a short to-do list of study topics for becoming a software engineer, but it grew to the large list you see today. After going through this study plan, I got hired as a Software Development Engineer at Amazon. <br/>
> This is my multi-month study plan for going from web developer (self-taught, no CS degree) to software engineer for a large company.
This clearly suggests a (big?) difference between a developer and an _engineer_.[^2] The latter sounds a cooler for sure. But what exactly would be required to make the jump from one title to the other, according to jwasham? The list is too long so let's make some abstractions:
This clearly suggests a (big?) difference between a developer and an _engineer_.[^2] The latter sounds a lot cooler for sure. But what exactly would be required to make the jump from one title to the other, according to jwasham? The list is too long so let's make some abstractions:
- Algorithms (including NP-completeness) and their complexity
- Data structures (including dynamic programming)

View File

@ -157,17 +157,17 @@ The section below contains practical snippets used by myself in some point in th
2. [Single HTML Manpage](http://www.scons.org/doc/HTML/scons-man.html#lbAF)
3. [SCons Construction Variables](http://www.scons.org/doc/0.96.90/HTML/scons-user/a3061.html) om bvb de compiler te specifiëren.
### Opsplitsen SConstruct en SConscript
### Separating SConstruct and SConscript
Waarom? http://www.scons.org/doc/2.1.0/HTML/scons-user/c3356.html
Why? http://www.scons.org/doc/2.1.0/HTML/scons-user/c3356.html
Build output definiëren, duplicate source files, etc. Voorbeeld `SConstruct` file:
Defining a build output, duplicating source files, etc. For example, in a `SConstruct` file:
```python
SConscript('SConscript', variant_dir######'build', duplicate0)
```
Voorbeeld file om Google Test mee te (proberen) builden `SConscript`:
This is an example file to build and run some GTest in `SConscript`:
```python
def Glob( pattern ###### '*.*', dir '.' ):
@ -192,90 +192,3 @@ env.SharedLibrary(target ###### 'gtest_main.dll', source ['../src/gtest-all.cc'
# after that, we should link with gtest_main
```
Poging tot converteren van deze voorbeeld `Makefile` - supplied bij de gtest sources:
```
# A sample Makefile for building Google Test and using it in user
# tests. Please tweak it to suit your environment and project. You
# may want to move it to your project's root directory.
#
# SYNOPSIS:
#
# make [all] - makes everything.
# make TARGET - makes the given target.
# make clean - removes all files generated by make.
# Please tweak the following variable definitions as needed by your
# project, except GTEST_HEADERS, which you can use in your own targets
# but shouldn't modify.
# Points to the root of Google Test, relative to where this file is.
# Remember to tweak this if you move this file.
GTEST_DIR = ..
# Where to find user code.
USER_DIR = ../samples
# Flags passed to the preprocessor.
# Set Google Test's header directory as a system directory, such that
# the compiler doesn't generate warnings in Google Test headers.
CPPFLAGS += -isystem $(GTEST_DIR)/include
# Flags passed to the C++ compiler.
CXXFLAGS += -g -Wall -Wextra -pthread
# All tests produced by this Makefile. Remember to add new tests you
# created to the list.
TESTS = sample1_unittest
# All Google Test headers. Usually you shouldn't change this
# definition.
GTEST_HEADERS = $(GTEST_DIR)/include/gtest/*.h <br/>
$(GTEST_DIR)/include/gtest/internal/*.h
# House-keeping build targets.
all : $(TESTS)
clean :
rm -f $(TESTS) gtest.a gtest_main.a *.o
# Builds gtest.a and gtest_main.a.
# Usually you shouldn't tweak such internal variables, indicated by a
# trailing _.
GTEST_SRCS_ = $(GTEST_DIR)/src/*.cc $(GTEST_DIR)/src/*.h $(GTEST_HEADERS)
# For simplicity and to avoid depending on Google Test's
# implementation details, the dependencies specified below are
# conservative and not optimized. This is fine as Google Test
# compiles fast and for ordinary users its source rarely changes.
gtest-all.o : $(GTEST_SRCS_)
$(CXX) $(CPPFLAGS) -I$(GTEST_DIR) $(CXXFLAGS) -c <br/>
$(GTEST_DIR)/src/gtest-all.cc
gtest_main.o : $(GTEST_SRCS_)
$(CXX) $(CPPFLAGS) -I$(GTEST_DIR) $(CXXFLAGS) -c <br/>
$(GTEST_DIR)/src/gtest_main.cc
gtest.a : gtest-all.o
$(AR) $(ARFLAGS) $@ $^
gtest_main.a : gtest-all.o gtest_main.o
$(AR) $(ARFLAGS) $@ $^
# Builds a sample test. A test should link with either gtest.a or
# gtest_main.a, depending on whether it defines its own main()
# function.
sample1.o : $(USER_DIR)/sample1.cc $(USER_DIR)/sample1.h $(GTEST_HEADERS)
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $(USER_DIR)/sample1.cc
sample1_unittest.o : $(USER_DIR)/sample1_unittest.cc <br/>
$(USER_DIR)/sample1.h $(GTEST_HEADERS)
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $(USER_DIR)/sample1_unittest.cc
sample1_unittest : sample1.o sample1_unittest.o gtest_main.a
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -lpthread $^ -o $@
```