This helps specify ordering for libraries that need it. Libraries with
a higher priority will be sorted earlier in the list, which can be
necessary when working with static libraries/archives.
The default value for "priority" is zero. It's only really necessary
to ensure relative ordering of particular pairings of libraries, so
it should be ok to use an absolute integer value for this. If you
need to order relative to a library, there is a good chance you're
adding it, or the place it's added is well known and you can easily
find its priority value. It's also unlikely that there would be a
complex series of interactions between libraries that would make a
more complicated system warranted.
Change-Id: Ie94a35e6563c07f8d462a4a52d0173ea3cf4f8de
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58350
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jui-min Lee <fcrh@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
In Python, "+=" operator for list acts more like append and list assign
doesn't make a copy. This will cause unexpected append to the orignal
list. Since we have multiple env to "declare", these functions will be
called multiple times and could wrongly append duplicated entries in
later calls.
Make a copy before appending the entries from filter to avoid this
problem.
Change-Id: I144d5054e4d93191ebc94b93291ff9a3f8a6c429
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58409
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
ProtoBuf files can (and should) be declared to SCons unconditionally,
but then also use a "protobuf" tag. This lets SCons still include them
conditionally when it gathers sources to build certain binaries without
having additional python logic in SConscripts, or manually interpreting
config state.
Change-Id: I9426d647bc2d6c9d7eee7dadba77f75ed83bcaad
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58349
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This makes what are configuration and what are internal SCons variables
explicit and separate, and makes it unnecessary to call out what
variables to export to C++.
These variables will also be plumbed into and out of kconfiglib in later
changes.
Change-Id: Iaf5e098d7404af06285c421dbdf8ef4171b3f001
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56892
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Sometimes a library is needed to support particular functionality in
gem5, and that functionality is only used (or even desirable) in
certain binaries SCons can build. We can currently filter sources to
include in a particular executable using tags, but libraries have been
added to the environment globally using the LIBS variable which applies
to all Executables.
This change adds a SourceLib() mechanism which is a new category of
source which represents libraries. This is independent from classes
which inherit from SourceFile which represent actual files, as opposed
to more abstract libraries.
When gem5 builds an executable, the filters it provides are used to
select both Source()-es, aka c/c++ files, and libraries. If something
like a unit test does not need all the libraries gem5 proper does,
then those won't be picked up by its filter, and it won't include them.
Change-Id: I003e029eb82f7800a7ecff698c260e2d18ea2900
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58069
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If TARGET_GPU_ISA is not set, even if the GPU ISA namespace isn't used
by anything, the logic which figures out what to set it to will fail.
This checks for that condition and sets it to something invalid, but
doesn't crash. If that namespace is actually used, then the build will
still fail.
Change-Id: Iec44255cccbafa4aceaa68bdd8b6a835dc0637a0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56895
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Before this patch, the protobuf builder would search for dependencies
only at the build directory. This works if the importing .proto file
imports paths relative to the build directory, but it results in a build
failure if imports are done relative to the source directory of the
importing file.
This patch adds the source directory of the importing file to the set of
paths searched for dependencies, which solves this issue.
Change-Id: I7debd467485a5087276ac005ac08ab01b32cb02e
Signed-off-by: Adrián Herrera Arcila <adrian.herrera@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55963
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Before this patch, the protobuf scanner would detect implicit
dependencies only if the import statement used a path relative to the
build directory. A path with a different format would result in a build
failure.
This is inconvenient because it impedes .proto files within a source
directory to import each other relative to that source.
Moreover, this is critical for EXTRAS directories with .proto files,
because the paths are forced to include the EXTRAS directory itself.
After this patch, the protobuf scanner uses the Classic scanner from
SCons to also detect implicit dependencies in the source path of the
importing .proto file. Regex management is also delegated to the Classic
scanner.
Change-Id: I1ad466813ef44947f3da07371805cb6376e392f0
Signed-off-by: Adrián Herrera Arcila <adrian.herrera@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55903
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This file populated the "cxx_config_directory" map from type names to
directory entry generating types. It used a comprehensive list of
includes of all SimObject headers, and a comprehensive list of the
generating types to fill everything in.
Instead, this change creates a new singleton helper class which, when
instantiated as a static member of a CxxConfigParams subclass, will
install a pointer to a CxxConfigDirectoryEntry to that map during global
object construction time.
Also, this change renames the map to cxxConfigDirectory which is in
compliance with the style guide, and puts it behind an accessor which
returns a static variable which is the actual map. This avoids any
problems that might come from global object construction order.
Change-Id: Iaa913fbe5af1b11d90ca618e29420eeb7cb0faed
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49455
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If there really are no c++ sim_objects in the file, then sim_objects can
be set to [] which it used to default to.
This way, if someone hasn't remembered to update their SConscript files
for the new sim_objects and enums parameters, this will give them some
indication what's wrong, rather than the build just failing later.
Change-Id: Ic1933f7b9dfff7dd7e403c6c84f1f510c8ee8c72
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54203
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Like gem5py which uses the same main source file, this program will run
arbitrary python scripts. Unlike the other program, it will include
support for the m5 module. That will make it capable of generating
SimObject param, enum, etc c++ files.
Change-Id: I15fd7545f6b1ea6559cbe27cef30c778867ebe70
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49421
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
I can't conclusively verify that this issue has been fixed because I
can't find any information about it on the internet. It's "SCons bug
2006" and "gem5 bug 308" but neither project still uses whatever bug
tracking mechanism those numbers correspond to. The change was mentioned
in the gem5 code base at least as early as 2008, and so hopefully has
been fixed in the last 13 years. I did a clean build without this
workaround, and things seem to work.
Change-Id: I155f0e72cb720fb5d35d8098375a45a69ea02263
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49419
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When calling a method in a superclass, you can/should use the super()
method to get a reference to that class. The python 2 version of that
method takes two parameters, the current class name, and the "self"
instance. The python 3 version takes no arguments. This is better for a
at least three reasons.
First, this version is less verbose because you don't have to specify
any arguments.
Second, you don't have to remember which argument goes where (I always
have to look it up), and you can't accidentally use the wrong class
name, or forget to update it if you copy code from a different class.
Third, this version will work correctly if you use a class decorator.
I don't know exactly how the mechanics of this work, but it is referred
to in a comment on this stackoverflow question:
https://stackoverflow.com/questions/681953/how-to-decorate-a-class
Change-Id: I427737c8f767e80da86cd245642e3b057121bc3b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52224
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
SCons does not use a variable called LDFLAGS, it uses one called
LINKFLAGS. Switch some errant uses to the correct name.
Also, adjust all the other variable names to use LINK, for consistency
and to avoid confusion and avoid mistakes in the future.
Change-Id: I38d40f5231afdf62bcfba04478d403d65e9b1e26
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51987
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When an object is a field in a union, it's the programmer's
resposibility to destroy it from the union's destructor. We can simply
neglect to do that and avoid having to use new to create the flags.
Also, we can define the flags as inline variables (a c++17 feature), and
then create a constexpr references to them. This lets us refer to debug
flags in constexpr objects, although we can't interact with them at, for
instance, construciton time or we'd lose our own constexpr-ness since
the actual object is not constexpr.
In c++20 we would hypothetically be able to use constexpr with new and
delete, but there may be additional restrictions that would make this
particular use impossible. Also this avoids leaking memory, which, even
though it's intentional, may confuse tools like valgrind.
Also, we need to ensure that all headers are included in some source
file so that they exist in the final executable, so that they show up in
the help, can be enabled/disabled, etc.
Change-Id: Ia43111d938e7af7140b1c17dd68135f426d0a1e9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49783
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jui-min Lee <fcrh@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The code which generated SimObject related param wrappers, cxx wrappers,
enum headers, etc was organized strangely. All the functions which
were used as SCons Actions were listed next to each other, and then all
the code which would set up each of those types of files and actually
use the Actions were next to each other.
This change rearranges that code so that the Action function is
immediately before the code which applies it. Or in other words, this
section of the SConscript is now grouped by the files being created,
rather than the type of the piece of machinery being defined to do that.
Change-Id: Ideee7bd44dac89c51840ec5970d95f6ccbbd1c8f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49402
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
The Executable class was used both for the generic gem5 target, and as a
base for the GTest binaries, the systemc test binaries, etc.
Unfortunately, the gem5 binary needs to include src/base/date.cc, and to
ensure that that file is up to date, it needs to depend on all the other
object files. No other binary should have that, but it was included by
inheritance.
Also, depending on the object file works well when those object files
and the date.cc object file are all part of the same binary and not
mixed and matched. That is not true for the GTest binaries for instance,
and so building a unit test would also build all the other unit test
object files because they are dependencies for date.to, date.tdo, etc.
If they already exist, then they would satisfy the dependency and not be
rebuilt.
Change-Id: Ia9cdddc5b2593678e714c08655eb440d7f5b5d1f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51088
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
It's really a part of the build system and not part of gem5, and so it
should probably live outside of the main tree. It would be confusing to
have a bunch of python scripts which don't end up inside gem5 alongside
a bunch of ones that do in src/python.
The directory is called build_tools instead of build so it doesn't get
confused with an actual build output directory.
Change-Id: Ie12475a15517508dc2044f0ca4db71a601b7ab6d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49393
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
The new c++ wrapper is called gem5py, and will run any python script
using gem5's embedded python interpreter. The "marshal" functionality is
split out into a separate python script gem5py can run.
The command line for gem5py should look like this:
gem5py ${SCRIPT TO RUN} ${ARGS TO THE SCRIPT}
So, for instance, to marshal a file called foo.py, the command line
might look like this:
gem5py python/marshal.py foo.py
Also, this change reorders the sources for the python embedding action
and limits the max_sources for Transform() to 1, so that it just shows
the python file being embedded and not gem5py or the marshal.py script.
Those are still sources so dependency tracking works correctly, but they
are also implied and just add visual noise to the build output.
Change-Id: I7ae6bd114973ae44c3b634884b6dafc6577e0788
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49392
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
We were simply not declaring the source files for PySource files if
built --without-python. Instead, we should declare them, but then
explicitly exclude them if that option is set.
Since we're already doing that, we can simply remove the check from the
PySource constructor.
Change-Id: I437ebeee1082fa00065bedd61f91d5721b915ae5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49389
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
