How to handle building files outside of directory - scons

I have a build set up and I'm struggling on how to handle one aspect.
I have successfully setup a variantdir for my project folder src build output, however I have
source that resides outside the project folder that needs to be build and included.
I am able to add the files I need into the build, however the object files are put into the external directory where the library souce files are.
Is there a standard way to solve this. I would like to avoid adding any scons files to the external directory as it is a standard intall of a tool.
What I attempted was to Mkdir() a temporary folder, Copy() the files, and build the files. This seems to work, but only the first time as the file permissions are set to readonly. Also, the only way to get it to work seemed to be to use the Execute() command which caused the action to happen at every build.

Have a look at the Repository() method (see http://scons.org/doc/production/HTML/scons-user.html#chap-repositories in the SCons UserGuide). It lets you sort of "mount" a folder to the top-level of your source tree. Then you can refer to them locally, and specifying "duplicate=1" for your variant dir should keep your remote folder clean from built files.
Hope this helps...

I was able to get the functionality I was looking for by building the objects in the external directory and then using the Move() Factory to move the object files.
If Anyone can point out a more 'scons'sy way of doing it please let me know.

Related

Copying files/folders to Electron Dist folder

Long story short:
I need to copy some files/directories over from my src folder to my dist/resources folder. Is there any way I can 'automatically' copy these files/folders over during packaging? I am using Electron-packager.
Long story:
I have a couple of folders containing JSON files that need to be read and copied over to a certain user directory. These are all done when I mount a certain component.
I use readFileSync() and using path.resolve with __dirname - but this generates an error since my relative path is different when I am running the packaged app (inside dist folder). Error is it cannot find my JSON file in dist/resources/config/settings.json. Also tried to check content of my app.asar but can't seem to find it there.
So my working workaround is to copy the directory/files over from my src folder to my dist/resources folder.
But this is kind of hacky and prone to forgetting. Is there any way I can 'automatically' copy these files/folders over during packaging?
I've seen a lot of questions like this and I've never really understood them. Maybe your project structure is very different than mine (below)?
Everything that is within my "app" directory is included by electron-packager (or electron-builder – I use both) and so it's all available when the app i packaged. In my case I have some Excel templates which the user can opt to save to disk but I could just as well create a directory and copy them there at first launch (haven't tried this but assuming permissions are ok I don't doubt that it will work). Maybe that is less "clean" than having a separate resources folder?
That said, I have seen this: Electron - How to add external files?

How to specify output directory for nuget binaries?

I have a nuget package which has .dlls files that it automatically copies to a directory when the program is compiled. Is there a way to specify where the dlls files will be copied to?
I know it's possible to modify the .targets file of the package but assume I don't have access to the package. The project is managed through git so I'd rather not have to distribute binaries along with the licenses included in the package. Currently when someone downloads/compiles the source, the nuget package is automatically downloaded through nuget restore. Is there a way to override the .targets file of the package?
I'd prefer not to use scripts to manage the dll files if possible. Also this is for a C++ project and I know nuget has restrictions based on the languages used.
If your question is asking if there's a simple configuration file or something similar where you can write "copy contents of package X to location Y", then no.
To most people, the difference between the various components in the build system are not important, so it doesn't matter to them if NuGet copies something or their project's SDK copies something, or MSBuild copies something. However, since you're now trying to do something more advanced, these differences may be important. NuGet only writes/copies files at restore (and therefore only to the packages folder, not the project output folder), but after restore, NuGet doesn't run at all. NuGet just makes the files known to the rest of the build system, and those components are responsible for deciding what to do. For example, where to copy files.
Since both C++ and .NET projects use MSBuild, the same debugging techniques can be used. From a "developer command prompt", build your project using the -bl switch to generate a "msbuild.binlog" file. You can open this file with the MSBuild structured log viewer. You can then use the search to find where in the build each dll is copied, and what the copy arguments (including destination) is. You can also look to find where the item that defined the file to be copied was created. Then, you can write an MSBuild target in your project file (or another file that gets imported by your project file) that runs at an appropriate time and updates the item to set the destination you want the file to be copied to. But, MSBuild is a scripting language, and you said you didn't want to write a script, so you might not like this approach. And if you're not already knowledgeable about MSBuild scripting, it's probably more effort than writing a powershell script. But at least it would happen automatically as part of the build (and therefore happen when you build and debug in Visual Studio), and not be some other process that needs to be manually run.

How to create a build.xml for a project that has multiple directories?

I have a Java project with the current directory structure:
Classes
Jars
Properties
Config
Each of these folders have some files which when I run make creates a project.
Now I have added another folder named client, which has two sub-folders: sampleRequests and YANG, along with one or two more files.
I do not know how to change my build.xml so that it incorporates the client folder and the sub-directories too.
I already have the build.xml for the earlier code where ai am copying my files. So lets say if I am using $out_dir for my project folder, can I simply use $out_dir/client/sampleRequests for this. Or the format is totally different. Stuck in a limbo. Please help.

Where should I put the nuspec file

I've searched the entire stackoverflow community but I couldn't find an answer for this...
I have a .nuspec file and I have no idea where I have to put it. Some topics say that I have to put it in the project directory and include in version control. Others say that its just keep the file in the same directory that the .nupkg file... but it doesn't worked to me. Any idea?
Thanks in advance.
A NUSpec file contains package metadata and is used to create a package.
A package is created from your project, which is why it would make sense to place the NUSpec file in the project folder.
It makes sense because it can then be committed to your source control as part of that project and this keeps everything in one place, it makes it easier to create the package automatically using your CI / CD pipeline.
You could, of course, do other things like create a NUSpec folder on the same level with your project folder and you could put your file there. Nuget.exe accepts a path to your NUSpec file so the actual location is irrelevant.
However, always consider your source control and how you manage / create this package, as long as you can do that easily, then place it wherever it makes sense to you.
You mentioned NPE, that doesn't really matter as behind the scenes it will more than likely call nuget.exe anyway. If you want to learn how to use it, have a look here : https://learn.microsoft.com/en-us/nuget/create-packages/creating-a-package.
They also recommend, as a convention, to have the nuspec file in the same location as the proj file.
As i understand from on of you comments you construct the package with the NPE.
As far as I remember the NPE was a ClickOnce application which opens up packages and you can put or even create packages there.
When the question is: Where do i put the nuspec within the package? the answer is: In the root folder of the package:
Otherwise the answer is already answered by the other answer.
Infos:
nuget packages are zip files
To get an idea where the nuspec resides in other packages just open one with NPE or 7zip
I had a look into the newtonsoft.json package
Unzipped it and it's obviously in the root folder of the package

Publish Web App files to different locations

I'm start to develop modules for DotNetNuke. I followed different tutorials(most by Chris Hammond) but there is something i don't like, and I'm searching a different way to do so.
He recommends to put a DotNetNuke installation, with IIS and SQL Server, on the developer PC and put your Project into the DesktopModules folder. I don't like it because i want to separate my project from DotNetNuke.
Is there a way to split the build/publish to different location like dll into folder x and all other stuff into folder y?
You could, but I don't really see the point. I see where you're coming from because it seemed awkward to me at first as well, but it really is the most efficient way to develop on the DNN platform. I have mine set up so all of my modules are in the same solution and branched in source from the root DNN folder. We don't keep the DNN core in source so the developer is responsible for that, although that may change at some point to keep versioning consistent.
By keeping your project located where it's installed, you can develop your modules the same way you'd develop any other web app you're building. If you make a change in markup you just have to save the file and refresh your page. If you change something in code just build and refresh.
If you really must keep them separate, you can absolutely do so (really the only benefit of this that I can see is that if you uninstall a module and accidentally click the checkbox to delete files - it happens - you don't have to worry about it). Create your project where you want it, change the Output Path to your DNN bin folder, and create post-build events to copy all of your .js, .ascx, and .css files (plus any others you may need - images, HTML files, XML files, etc.) to appropriate folder(s) in the DesktopModules folder. Just remember that you have to build the project every time you make ANY changes to test them, and you have to write/change your post-build events every time you add a new type of resource, change/add a directory, etc.
Either that or you can build an install package and uninstall/reinstall the module every time you change some padding in your stylesheet ... but I'd stick with keeping the project in the DesktopModules folder.
Sure you can do that.
Set up your solution and module projects anywhere, build the projects and copy the appropriate parts (such as the *.ascx , *.ascx.resx, *.dnn files) back to your website folder -
website/ DesktopModules/Your_module_name
Copy the module dll to the website's bin and you good to go.

Resources