I know you can't include projects with the same name, that makes sense, but why does following not work:
include(":app:core")
include(":library1:core")
include(":library2:core")
I want the folding feature of the IDE that this approach brings as a side effect, but because all 3 projects end on "core" this fails when building the project.
Can this problem be solved OTHER than following:
include(":app-core")
project(":app-core").projectDir = file("app/core")
include(":library1-core")
project(":library1-core").projectDir = file("library1/core")
include(":library2-core")
project(":library2-core").projectDir = file("library2/core")
Using "-" or "." as separator does solve the compiling issue but then the IDE does not fold the projects anymore...
I really like to use the ":" style inside my open source libraries but when I want to include them in an app I get problems because more than one of my libraries has a core module...
Question
I wonder if there is some setting or other trick to get the folding inside the IDE and have the ability to have multiple core modules inside a project but in different paths and use those 2 features together.
What is the build failure that you see?
I'm successfully using a multiproject build that has multiple subprojects with the same project name under different paths. The only change I had to make was this:
allprojects {
extensions.findByType<BasePluginExtension>()?.apply {
archivesName.set("myproject" + path.replace(":", "-"))
}
}
I did it for allprojects in the root build.gradle.kts, but you could also do it individually for each affected project.
This ensures that each library gets a unique filename for the .jar containing its classes.
Without the change, :library1:core and :library2:core would both end up being built as core.jar and would conflict at runtime. After the change, I get myproject-library1-core.jar and myproject-library2-core.jar, and everything works fine.
Related
I sometimes create C#-based software that consists of multiple projects inside one solution. The assemblies created from the projects should go into different output directories.
As a simple example, consider this:
myApplication
|- MainApplication.exe
|- PluginInterfaces.dll
\- plugins
\- SamplePlugin.dll
That would be the result of a solution with three projects inside.
In former versions of Visual Studio (I am not exactly sure when the switch happened - maybe from VS 2019 to VS 2022, as VS 2022 was the first version where I became aware of the issue?), I could use the project settings to set an output path for each project.
As the output path contained the build configuration, I had to set this output path for each project and each build configuration, which was slightly cumbersome, but still, it would get the job done.
In the above example, this would result in the following settings:
Project
Debug Output Path
Release Output Path
MainApplication
..\..\bin\Debug\
..\..\bin\Release\
PluginInterfaces
..\..\bin\Debug\
..\..\bin\Release\
SamplePlugin
..\..\bin\Debug\plugins\
..\..\bin\Release\plugins\
Now, I just became aware this looks a bit different in VS 2022 - there now is a single, configuration-agnostic setting called "Base Output Path".
This way, the build configuration (and target framework) will be added automatically after the base output path.
While this is somewhat more convenient, I now face the problem that it makes no sense anymore to assign different base output paths to individual projects, unless I want to have the resulting assemblies end up in completely separate folder trees.
If there is no setting in VS to work around that, I presume I could edit the .csproj file to somehow directly influence the output path - ways to do this are mentioned in another answer, though its author cautions that it may have undesirable side-effects for the build-logic.
FWIW, I have actually tried modifying the <OutputPath> like this:
<OutputPath>$(BaseOutputPath)$(PlatformName)\$(Configuration)\plugins\</OutputPath>
Unfortunately, the platform for some reason gets appended after that path.
Same if I use <OutDir> instead of <OutputPath>.
Another possible approach could be just compiling to the default locations, then using a post-build event to copy everything to the final location - but then, I fear launching the application from VS for debugging would not take the assemblies from their final (copied to) location.
What is an effective way to configure my projects so the output forms a folder tree, while not risking to run into any side-effects by circumventing default behaviour?
It appears I can achieve the desired result with the following settings in my .csproj file:
<BaseOutputPath>..\..\bin\</BaseOutputPath>
<OutDir>$(BaseOutputPath)\$(Configuration)\$(TargetFramework)\plugins\</OutDir>
I am not sure why it works like this - looking at the source, I had actually expected also having to specify
<AppendTargetFrameworkToOutputPath>False</AppendTargetFrameworkToOutputPath>
but apparently, that was not necessary - the additional targt framework mention after \plugins\ is gone already once I force the target framework to appear in front of it.
(Now, I am not yet sure this does not provoke any undesirable side-effects, so I'm going to leave this answer open for a while rather than marking it as accepted right away.)
How do I add a Static Library to a VS 2015 Fortran Project?
I've searched for the answer to this question online, but the solutions I've found (linked below) don't seem to work for me.
How to link a .LIB in a MS Visual Studio / Intel Fortran project?
https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/393843
I'm using VS 2015 and Intel Fortran 2017.
I have created a static library from my Utilities project and I would like to be able to use the 'Utilities.lib' file in a different project (PhysicsCore) without having all of the source included.
I've tried dragging and dropping the 'Utilities.lib' file into the PhysicsCore Project. I've tried adding existing file and adding 'Utilities.lib'. I've tried adding the lib file and all of the '.mod' and '.obj' files. I've tried going under properties -> librarian -> additional dependencies. All of these end with the PhysicsCore project failing to compile due to missing procedures and modules.
I have gotten it to work one way that isn't very helpful. I have added a new project to the solution and then added in all of the '.obj' and '.mod' files and the '.lib' file. Changed the solution settings to not rebuild that project. And then finally added that non-building project as a dependency of the PhysicsCore project.
I feel like I must just be missing something small.
EDIT: years later. I finally came across the issue. If the library were all in .f90 files everything would work fine, but I'm using modules which require the .mod files. Everything was doing what it was supposed to as far as I can tell; however, it didn't behave the way I expected it to.
There are several ways:
Drag the .lib into the project as a source file. You say this didn't work, but it always has when I have done it.
In the Linker project properties, add the full path to the .lib to Linker > Input > Additional Dependencies, or just add the .lib name there and add the directory path to Linker > General > Additional Library Directories.
If the parent project is also Fortran, right click on the parent project, select Build Dependencies > Project Dependencies. Check the box for the library project. (This does not work if the parent project is not Fortran.)
I would generally recommend #3, as this will also make the .mod files from the library project visible to the parent project. If you choose one of the other methods, you then also have to make any include or .mod files visible by adding the directory path to the project property Fortran > General > Additional Include Directories.
If you need more help with this, I suggest asking in https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows
In the project I'm working on, I need to process certain filetypes with a custom command (building assemblies, namely, due to certain plugin / toolchain limitations, which are beside the point). This is configured from our premake script:
filter { "files:*.extension" }
buildcommands("blah.exe %(FullPath) --my --args")
buildoutputs("$(OutDir)%(FileName).obj")
The project will fail to build unless I set the Properties -> Custom Build Tool -> Link Objects property to No for each individual *.extension item. (These should not be linked as part of the custom step anyway.)
How can I configure this particular property from our premake script without resorting to hacks? (e.g. Anything similar to xcodebuildsettings)
Looks like a more recent master of premake supports a linkObjects file configuration function that does just that (not yet in the docs). Up we date...
Until then, one possible hack is to use buildmessage("false") then do a find-replace all in the generated project files for the Message XML tag to LinkObjects.
I am trying to integrate one application into another and I thought that a simple way of doing this may be to add the one application into another. (Simply going to File->Add Files to "Project")
However, when I do this and try to use files that are in that other project, it says that the files can not be found. Am I doing something wrong, or is doing this even the correct way of going about this?
Depending on what you're trying to do, you could either just import the source files (not the project file itself), or you could make the part of the original project you want to use into a framework (library). Then you import the entire framework in one step.
You just add the project (project A) and configure it as a dependency of the app (project B).
If it's iOS, you likely want to deal with this shared program using a library.
If OS X, then you still need to link to what symbols you reference (e.g. create a library). If you just want to bundle a helper app or executable with your app, add it as a dependency, then you'll probably want to copy the product (project A.app) as a resource to your bundle of project B.app. If you only want to build or test, then a simple dependency will do.
If you're really sharing sources, look into using a library (static, dynamic, framework) rather than copying your sources or their references.
I am writing a small application at the moment and am trying to organise my build output to be a little closer to the finished product. The application is made up of a number of different projects. There is a core library that contains most of the functionality, a GUI app and a command line app that both reference the Core Dll, and a number of Plugin Dlls that are loaded at runtime and implement different data sources, these all reference core.dll, these also may include some other third party dlls. There are also a number of peripheral files such as a readme. And finally the core.dll and the datasource plugins are unit tested.
I would like to configure my build so that everything is output into directories as I would expect it to be when installed. I want debug and release builds to be built into different directories but otherwise have the same directory structure. I only want tests to be built for debug builds, and want them to be runnable, but seperated (I guess all test dlls would get output into a seperate directory). Here is how I imagine the structure will be.
Code/
solutions etc here
Debug/
Project.Core.dll
Project.Gui.exe
Project.Cli.exe
readme.txt
lib/
ThirdParty1.dll
ThirdParty2.dll
DataSource/
DataSource1.dll
DataSource2.dll
Tests/
Project.Core.Tests.dll
DataSource1.Tests.dll
Release/
same as Debug but without tests.
Is there any way of getting a solution to build like this? I'm beginning to think it will be difficult to build the plugins and the app all from one solution, and probably not even wise, but as they will all be distributed together it would be nice. I am open to using Nant or another build tool if that will make it simpler.
It is possible. Just modify OutputPath tag manually in each .csproj in both Debug and Release file to something like this
<OutputPath>..\$(Configuration)\any_subdirs</OutputPath>
You can disable tests building for Release using Configuration manager.
Modifying each project every time you create a new one is annoying.
Here's the solution:
Locate the real vs project, it'll be somewhere under ("%programfiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplates*")
Copy it locally somewhere.
Extract it.
Edit the contents making changes that better suit your project layout style. Make sure you update the project name, the name is what you see when looking for the project in the new project dialogue box. It's xml tag is Name, you'll find it in the {something}.vstemplate file.
Compress the content again. (Note: the contents must NOT be in a sub folder, so /* and NOT /{somefolder}/*).
Place your custom project under ("%USERPROFILE%\Documents\Visual Studio 2010\Templates\ProjectTemplates*").
Add a new project is Visual Studio, selecting your custom one, and enjoy!