Thank you very much for your help, Mike! :-)
This now works. More about that below...
I can see a few problems in implementing tup as a build-system in IDEs. The
"pushing everything to the top-level" approach works against best practices.
With object orientation we moved strongly into "divide and conquer". A
problem too big, gets split into smaller problems, which then are split
into even smaller problems, etc...
This is being reflected by the paradigm of modern programming languages,
such as C++. Hence, you will find complex classes that are built upon
inheritance and containment. These are typically managed as a project,
which contains sub-projects. The IDEs support this paradigm.
It is important that the sub-projects can be seen as "independent units".
Typically, they come with their own unit tests. They might also be used by
other code.
Likewise, this is being reflected when working on projects. While you work
on a sub-project of a sub-project, you don't expect the whole (top-level)
project to compile (yet) necessarily.
How about having a tag/command/variable that defines a directory as
project, module, unit or whatever you may call it?
The beauty of this would be that you could, henceforth, reference this
"project" by name. You could even move it and tup would still assign the
paths correctly.
This should make it easier to keep local things local.
Furthermore, you may need to be able to compile a single file from a
certain project, with all the specified options and flags. In an IDE this
is one of the most common tasks: "Try compiling what I got in front of my
nose here; I wanna see what errors pop up." (compile current file). In
other words: "Build the file xyz.cpp from project abc" with the project's
flags and options.
I case you're wondering about the fixes – Mike already fixed it up pretty
well:
I moved the tup-configs to the top level and had it create the build-*
folders there. Therefore, in src there is now only this Tupfile (plus
sources and headers, of course):
# Tupfile in config_module/src
CPPFLAGS += -std=c++17
CPPFLAGS += -Wall
include_rules
: foreach *.cpp |> g++ $(CPPFLAGS) -c %f -o %o |> %B.o
The Tuprules.tup got moved to the top-level as well and changed to this:
# Tuprules.tup in config_module
LDFLAGS += -Wl,-lstdc++fs
ifeq (@(BUILD_TYPE),debug)
# debug build:
CPPFLAGS += -march=native
CPPFLAGS += -ggdb3
CPPFLAGS += -D_GLIBCXX_DEBUG
else
ifeq (@(BUILD_TYPE),release)
CPPFLAGS += -march=native
CPPFLAGS += -O2 -s -flto
LDFLAGS += -Wl,--as-needed
else
ifeq (@(BUILD_TYPE),static)
CPPFLAGS += -static -Os -s -flto
LDFLAGS += -Wl,--as-needed
else
error "Build type not set or wrong!"
endif
endif
endif
… and the top-level Tupfile now looks like that:
# Tupfile in config_module
MY_CONFIG_FOLDER = $(TUP_CWD)/debug_config_folder
CPPFLAGS += -std=c++17
CPPFLAGS += -Wall
CPPFLAGS += -Isrc
include_rules
: foreach *.cpp |> g++ $(CPPFLAGS) -DMY_CONFIG_FOLDER=$(MY_CONFIG_FOLDER)
-c %f -o %o |> %B.o
: src/*.o *.o |> g++ $(CPPFLAGS) $(LDFLAGS) %f -o %o |> test_config
This seems to work nicely. :-)
--
--
tup-users mailing list
email: [email protected]
unsubscribe: [email protected]
options: http://groups.google.com/group/tup-users?hl=en
---
You received this message because you are subscribed to the Google Groups
"tup-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tup-users/fbf1c49f-59db-47b6-a291-fda5553d6306o%40googlegroups.com.
