coapp / coapp.org Goto Github PK

Currently, there is no tutorial with very first steps for CoApp for package creators, especially there is no article explaining that in order to create new packages:

• tools required are...
• environment configuration required is...
• optional useful tools are...

Simply, similar article to Setting up the development environment in section I want to help build CoApp, but dedicated to package creators would be helpful.

I guess, it could be Setting up the packaging environment in the section I want to help build CoApp Packages.

The link to http://downloads.coapp.org/files/autopackage.xml in building-a-package.html.md is broken.

Trying to get help with CoApp from the website, and I'm having some problems....

I don't think this is a proxy issue at my end but I could be wrong. Neither Chrome nor IE 11 are working.

Screenshot attached

Assigning to myself as a reminder. I just tried to set up SSH keys for CoApp's GitHub on a brand new Git/Git Extensions install. It's still possible to tie yourself in knots with various versions of ssh/putty.exe - I think forking the Git Extensions installer is in order.

• GE should use a local copy of plink/putty rather than installing its own
• There should be a way to provide a setup checklist (I'm remembering the SQL Server setup UI here) and check various configs on the user's system - Git Extensions itself has one, but it confused me more because it was validating its own copy of Putty.
• Git Environment setup is a bit hairy - especially if you're running in Powershell, it's not a good idea to add C:\Program Files (x86)\Git\bin to the path - it contains quite a few Cygwin-y utilities which clash with Powershell aliases.
  • PS specific, but when I Set-Alias git C:.... it worked up until I called coapp-src.cmd, because of course the batch file doesn't know about my aliases. In this instance it was eaiser to edit the DVCS variable in the batch file...
  • There is a plink command which would stop the "Host key is not cached"-related problems - might be worth adding this to the doco.
• May be worth my time to fork GitHub's setup info and tailor it for CoApp

The current readily publicly available copy of coapp-src.cmd does not include the packages listed below, which are critical to building the current coapp-tools.sln (as provided by this same file from the master repository).

• CoApp/AzureSyncbox
• CoApp/AnyGen
• CoApp/ToolScanner

A link to the referenced file is provided below:
https://github.com/downloads/fearthecowboy/coapp/coapp-src.cmd

It's a spam magnet and serves no purpose anymore. @fearthecowboy

ported from : https://nuget.codeplex.com/workitem/3702
I'm trying to build native nuget package for Google C++ Testing Framework as described at http://coapp.org/reference/autopackage-ref.html#Pivots. It's ok for v110, v100, v110_xp toolsets. But I failed to build package for "LLVM-vs2012" and "Intel C++ Compiler XE 14.0" platform toolsets. The command "Write-NuGetPackage" fails when there is any space of '-' character in the platform toolset choices list.

By default CoApp creates three packages: Main, Redist and Symbols. Main depends on Redist.
Is it possible to specify whether to create dependency on Redist package or not? Because it is not always necessary to have dll files. It can be enough just to have possibility to build the project. As far as I see all Redist does is copying binaries to target directory. Actually if you have many projects (1 exe and many dlls) that depends on the same nuget package in your solution then you need to execute copying only once for exe file. This could have perfect sense in case if your dlls have target directory different than main exe file. Currently I got nuget binaries copied to every directory with my dll.

Setup is as follows:

N - some nuget package (distrib package contains n.dll)
In solution, say, I have:
Exe project uses N and outputs to C:\Exe
Dll project uses N and outputs to C:\Exe\PlugIn\

After build I got n.dll copied to both directories: C:\Exe\ and C:\Exe\PlugIn\

Could you fix it?

I'm trying to create an internal Boost Date Time package. I don't want to use the one already available online because we do internal builds and store the symbols.
There's a convention in my company that all the external code resides in a folder whose path is specified by an environment variable.
Here's the script i'm using:

nuget {

    nuspec {
        id = boost.date_time;
        version: 1.57.0;
        title: Boost Date Time Library;
        authors: {BOOST};
        owners: {BOOST};
        licenseUrl: "http://www.boost.org/users/license.html";
        projectUrl: "http://www.boost.org/";
        iconUrl:
        requireLicenseAcceptance: false;
        summary: A set of date-time libraries based on generic programming concepts.;
        description: A set of date-time libraries based on generic programming concepts.; 
        releaseNotes: "See http://www.boost.org/doc/libs/1_57_0/doc/html/date_time.html";
        copyright: Copyright 2014;
        tags: {};
    };

    files {

            #defines {
                INCLUDE = ${EXTERNALS_PATH}\boost_1_57_0\include\boost\;
                SDK = ${EXTERNALS_PATH}\boost_1_57_0\v120\;
                VERSION = 1_57;
            };

        nestedInclude: {
            #destination = ${d_include}\boost_1_57_0\include\boost\date_time;
             "${INCLUDE}date_time\**\*"
        };

        [x86,v120,debug] {  
            lib: ${SDK}Win32\boost_date_time-vc120-mt-gd-${VERSION}.lib;
            bin: ${SDK}Win32\boost_date_time-vc120-mt-gd-${VERSION}.dll;
        }

        [x86,v120,release] {  
            lib: ${SDK}Win32\boost_date_time-vc120-mt-${VERSION}.lib;
            bin: ${SDK}Win32\boost_date_time-vc120-mt-${VERSION}.dll;
        }

        [x64,v120,debug] {  
            lib: ${SDK}x64\boost_date_time-vc120-mt-gd-${VERSION}.lib;
            bin: ${SDK}x64\boost_date_time-vc120-mt-gd-${VERSION}.dll;
        }

        [x64,v120,release] {  
            lib: ${SDK}x64\boost_date_time-vc120-mt-${VERSION}.lib;
            bin: ${SDK}x64\boost_date_time-vc120-mt-${VERSION}.dll;
        }
    }
}

When I run this script i get the following warnings:

PS C:\Workspace\foundations\sw_foundations\release\boost> Write-NuGetPackage .\date_time.autopkg
WARNING: ProcessNugetFiles:WARNING: file selection 'C:\workspace\externals\boost_1_57_0\include\boost\date_time\**\*'
failed to find any files
WARNING: ProcessNugetFiles:WARNING: file selection
'C:\workspace\externals\boost_1_57_0\v120\Win32\boost_date_time-vc120-mt-gd-1_57.lib' failed to find any files
WARNING: ProcessNugetFiles:WARNING: file selection
'C:\workspace\externals\boost_1_57_0\v120\Win32\boost_date_time-vc120-mt-gd-1_57.dll' failed to find any files
WARNING: ProcessNugetFiles:WARNING: file selection
'C:\workspace\externals\boost_1_57_0\v120\Win32\boost_date_time-vc120-mt-1_57.lib' failed to find any files
WARNING: ProcessNugetFiles:WARNING: file selection
'C:\workspace\externals\boost_1_57_0\v120\Win32\boost_date_time-vc120-mt-1_57.dll' failed to find any files
WARNING: ProcessNugetFiles:WARNING: file selection
'C:\workspace\externals\boost_1_57_0\v120\x64\boost_date_time-vc120-mt-gd-1_57.lib' failed to find any files
WARNING: ProcessNugetFiles:WARNING: file selection
'C:\workspace\externals\boost_1_57_0\v120\x64\boost_date_time-vc120-mt-gd-1_57.dll' failed to find any files
WARNING: ProcessNugetFiles:WARNING: file selection
'C:\workspace\externals\boost_1_57_0\v120\x64\boost_date_time-vc120-mt-1_57.lib' failed to find any files
WARNING: ProcessNugetFiles:WARNING: file selection
'C:\workspace\externals\boost_1_57_0\v120\x64\boost_date_time-vc120-mt-1_57.dll' failed to find any files

But all these files exist and these are their correct paths.

When I put the same script in the directory where boost resides and change INCLUDE and SDK to use relative paths the package builds successfully and correctly.

I was trying to get familiar with the coapp forking process and noticed that the site is not available. I clicked around and found more deadlinks:

On the information page, that is "Information.markdown":

• http://www.coapp.org/Blueprints/X._Archives_of_older_pages/Packages
• http://www.coapp.org/Blueprints/Software/Developer_Tools
• http://www.coapp.org/Blueprints/Software/Client_Software
• http://www.coapp.org/User_Stories/Publishing_Packages

There may be more. But especially the first link about shallow forking should be restored/made available ASAP (for the contest)!