We have an Unreal Engine project where we build the plugins separately. They are build on ADOS agents, and as such they have a path like /path/to/agent/_build/_work/XYZ/s/Packaged/PLUGIN_NAME/...
where XYZ is more or less random number. Since the number can change depending on the agent and us cleaning up the _build folder, setting substitute paths in gdb is really cumbersome - we'd have to add some 150 paths for every plugin we use.
Is there a way around this? Ideally, I would like to have something like
set substitute-path /path/to/agent/_build/_work/*/s/Packaged/PLUGIN_NAME/... /path/to/PLUGIN_NAME/...
But that asterisk use in particular doesn't seem to work.
Related
I have a script library stored in .../lib/ that I want to embed into my program. So far, that sounds simple: On Windows, I'd use Windows Resource Files - on MacOS, I'd put them into a Resource folder and use the proper API to access the current bundle and it's resources. On plain Linux, I am not too sure how to do it... But, I want to be cross-platform anyway.
Now, I know that there are tools like IncBin (https://github.com/graphitemaster/incbin) and alike, but they are best used for single files. What I have, however, might even require some kind of file system abstraction.
So here is the few guesses and estimates I did. I'd like to know if there is possibly a better solution - or others, in general.
Create a Zip file and use MiniZ in order to read it's contents off a char array. Basically, running the zip file through IncBin and passing it as a buffer to MiniZ to let me work on that.
Use an abstracted FS layer like PhysicsFS or TTVFS and add the possibility to work off a Zip file or any other kind of archive.
Are there other solutions? Thanks!
I had this same issue, and I solved it by locating the library relative to argv[0]. But that only works if you invoke the program by its absolute path -- i.e., not via $PATH in the shell. So I invoke my program by a one-line script in ~/bin, or any other directory that's in your search path:
exec /wherever/bin/program "$#"
When the program is run, argv[0] is set to "/wherever/bin/program", and it knows to look in "/wherever/lib" for the related scripts.
Of course if you're installing directly into standard locations, you can rely on the standard directory structure, such as /usr/local/bin/program for the executable and /etc/program for related scripts & config files. The technique above is just when you want to be able to install a whole bundle in an arbitrary place.
EDIT: If you don't want the one-line shell script, you can also say:
alias program=/wherever/bin/program
I'm still struggling with waf for setting up different set of flags for subprojects.
I have a structure like this, in which superproject recursed to the subprojects:
superproject/wscript
libproject/wscript
progproject/wscript
The problem is that both subprojects progrproject and libproject use boost tool.
I want that both projects check for boost at configuration time, since I want the projects to be self-contained when they are built independently.
I have to do something like this to not overwrite flags for boost between subprojects:
#In libproject
cfg.check_boost('regex', uselib_store='BOOST_LIBPROJECT')
#In progrpoject
cfg.check_boost('program_options', uselib_store='BOOST_PROGPROJECT')
This has the side-effect of making options --boost-libsand --boost-includesdefaults not to work anymore.
Actually, I would like to use the default BOOST store for both, but one seems to overwrite the other in _cache.py file. If I build the projects alone and separate, this problem does not happen. I think setting another environment is not a solution (right?)
since this makes the command to become ./waf build_libproject or similar, which is not what I want.
I want:
./waf configure build
to run correctly without workarounding with different stores or preventive flag name changing.
What is the correct way to do it?
I am converting a project from autotools to waf with the hope that it can be easily compiled in windows as well.
I am using a super project with two children folders that are 2 projects.
One of them is a library, the other, a program, like this:
superproject/wscript
superproject/libraryproject/wscript
superproject/programproject/wscript
It seems that waf has terrible support for subprojects. I have a wscript in each of these directories.
I recurse from superproject into the 2 other projects, but the _cache.py file is shared for both projects. This has the following side effects (issues):
When using the boost tool, I had to use it like this to avoid name collisions:
# In library project
cfg.check_boost('boost_program_options', uselib_store='BOOST_LIBRARYPROJECT')
# In program project
cfg.check_boost('boost_program_options', uselib_store='BOOST_PROGRAMPROJECT')
boost-libs and boost-includes command line options are also lost by default, so I have to set them manually, like this:
cfg.env.LIBPATH_BOOST_PROGRAMPROJECT = cfg.options.boost_libs
...
The _cache.py file is overwritten by the programproject/wscript, loosing all the configuration for the flags.
Questions:
Is there any good way to nest projects and avoid at least issue 2?
Is there any reasonable way to avoid both that doesn't require a script and building projects separately?
Configuration file is not written twice.
My mistake was to do this:
cfg.env = ConfigSet()
I wanted a new and clean ConfigSet but doing that in both projects made the first set of flags to be lost.
Since the environment seems to be shared among all project configurations, is it good style to name the variables with custom names? For example, instead of using:
cfg.check_boost('program_options')
Should I use:
cfg.check_boost('program_options', uselib_store='BOOST_MYPROGRAMPROJECT')
Is this good style or it's usually done in another way?
Can be done in a cleaner way deriving ConfigSets?
I'm using SCons to build a very large project, with many buildable sub-projects. I can easily use keyword commands like scons group=ai to build the AI sub-projects with if statements (choosing the right SConscripts based on the keyword command), but I want to make it as easy as possible for others to use scons. Ideally, I'd like to use it like so: scons ai to build the AI components. However, the only single-word command functionality I've found in SCons so far is aliasing, and all the examples are about changing the target. This is not what I want. Since I have a very large project with multiple sub-SConscript files to build the subprojects, I want to call the SConscripts selectively. I've tried code like so:
env.Alias("ai", SConscript("ai/SConscript", 'env'))
but this calls the AI SConscript every time, regardless of whether I use the "ai" alias or a different one. Does anyone know if it is possible to use aliasing this way to selectively call SConscripts based on the alias?
As you mentioned, the Alias() function is only used for targets. I can think of 2 ways to solve this
Alias() can be called multiple times for the same alias with different targets, so you could call it for all targets in each SConscript, then you could build everything in a SConscript. Here's an example of what I mean:
ai/SConscript:
# targets, etc
env.Alias("ai", target1)
env.Alias("ai", target2)
...
env.Alias("ai", targetn)
Another option would be to put some logic in your root SConstruct so it only calls sub-project SConscript's based on a command line argument. This option would require you to use a command line argument of this form: group=ai
I have a TeamCity Build Configuration that includes the following to publish artifacts:
Source\Builder\bin\Release\*.dll=>release
This works fine, however I am wanting to exclude one dll (there are quite a few) and have read that you can use + & - operators to do this. Something along the lines of:
+: Source\Builder\bin\Release\*.dll=>release
-: Source\Builder\bin\Release\Builder.*
As soon as I add these in, no artifacts are published and I get the following error in the build log (looks like it is counting the + as part of the path):
[Publishing artifacts] Collecting files to publish [+:Source\Builder\bin\Release\*.dll=>release]
[Publishing artifacts] Artifacts path +:Source/Builder/bin/Release/*.dll not found
I am using version 7.1.1, anyone any ideas (I am not sure whether these operators are even valid). I have seen a solution with MSBuild but am surprised this functionality is not available.
Thanks in advance.
I don't believe you can.
However, if you are using the artifacts in another build configuration as an artifact dependency, you can exclude a particular file there.
When you set up the dependencies, you can specify a negative operator like this:
+:release/**=>Dependencies/SomeProject
-:release/SomeBinary.dll
It is a horrible hack, but one way you could get it to work would be to set up a new build configuration which gets the dependencies as an artifact dependency, excluding the one binary, and then publishes its own artifacts.
As in, create a new build configuration and publish:
Dependencies/SomeProject=>release
Then reference the artifacts from this build configuration instead of the other one.
A little bit late for the party, but there is still no fix...
I ended up adding a last build step to the project. It is command line > custom script. Then I used this commands to remove the files that I didn't want in the artifacts. This runs just before artifacts collection.
del /S /Q "src\apps\*.xml"
del /S /Q "src\apps\*.pdb"
Explanation for del command
/S Delete from all Subfolders (DELTREE)
/Q Quiet mode, do not give a Yes/No Prompt before deleting
* Match any characters
Our current options are to vote for this feature request at
http://youtrack.jetbrains.com/issue/TW-5244 and fail back to workarounds.
TeamCity artifact paths combine folders question hints that the same target folder can be reused for multiple path patterns.
TeamCity docs also state that
TeamCity will create directories starting from the first occurrence of
the wildcard in the pattern.
So in many cases it's possible to inverse exclusion problem to multiple inclusions.
For example, instead of lurking how to exclude -:**/.svn from my templates I was able just to filter them by extension:
templates/**/*.vm => templates
templates/**/*.xsl => templates