Say I have a project A that depends on project B and that B takes a long time to build.
Both project A and project B use tup.
I already have B built in its separate directory.
Can I now copy B into A or create a submodules that points to B, add the build products (cp -a), and convince tup that the build products are fine?
Related
I have a WiX Custom Bootstrapper that install several msi packages, let’s say package A, B, C, D and E. Now I want to distribute a new Bootstrapper that upgrade package A and B but no longer install package C, D and E. The problem is that I want to leave package C, D and E on the machine (if already there).
When upgrading, the Bootstrapper will install/upgrade package A and B, then uninstall the old Bootstrapper to clean up. That will uninstall package C, D and E because they are no longer a part of the product.
Question: How can I prevent that package C, D and E being uninstalled?
#Shique: If the packages (C, D and E) are no longer included in the Bootstrapper, you will never hit OnPlanPackageBegin on those packages and can therefore not set the State property to RequestState.None.
This is not a direct answer to the question but a way to remove packages, that you no longer want to distribute, from you bootstrapper without uninstalling the packages.
We created a second Bootstrapper containing package C, D and E. In our original Bootstrapper, now only containing package A and B, we added the second Bootstrapper as an ExePackage with the Permanent attribute on.
When running the original Bootstrapper it will upgrade package A and B, run the second Bootstrapper, that will increment the reference count on package C, D and E. When the Bootstrapper comes to the cleanup, it will of course leave package A and B, but also package C, D and E due to the reference from the second Bootstrapper.
If the package C, D and E are not embedded (compressed) in the second Bootstrapper remember to add them as Payload to the ExePackage.
In this way we still have a handle to package C, D and E through Apps & features and the user can choose the time to uninstall the packages.
I have a cpp cmake project that takes a bit to compile the core components.
Let's say
Component A (Takes 2 hours to compile)
Component B (Takes 1 hour to compile)
Component C needs to statically link in Component A and B (takes 5 minutes)
We mostly are only changing Component C.
But we want our PR Build gates to rebuild A and B if they have to, but not necessarily if there wasn't any changes.
I'd like to build component A and B once per night.
Then during the day, allow our PR gates to download the intermediates from them, and then do an incremental build, only rebuilding the parts that have changed.
However, cmake seems to embed a lot of folder path information into the intermediates/ cache stamp files and stuff. And our build machines have slightly different paths each time. (e.g. c:\repo###\sourceDir\
and the ### changes each time.
Is there any easy way to do this? Or do I have to 'modify all the relevant .txt, .tlog, cache text, etc.. files' and also manipulate the timestamps back to their originals after modifying the files path to match the current machine.
I tried just copying over the /intermediates/ folder with all the .obj and other things, but I think cmake is picky about the folderpaths.
And I don't want to consume the prebuilt .lib or .dll from component A or B, because we might have made a change to them, so it should do incremental in that case.
Edit/answers
I haven't looked into ccache yet, hadn't heard of it.
we evoke it via cmake.exe (configure/build/install) cmakelists.txt. Each component does have their own cmakelists.txt in a toplevelfolder
src/componentA/cmakelists.txt (controls everything in itself, has no ledge of B or C)
src/componentA/cmakelists.txt (controls everything in itself, has no ledge of A or C)
src/componentC/cmakelists.txt (controls everything in itself + include from A and B)
I have a directory like this:
htdocs
- shared
- project 1
- css
- JS
- project 2
- css
- JS
etc.
Now I want to create 2 projects, one with the folders shared and project1 and one with the folders shared and project2.
The first project I can create with htdocs as a root folder, and exclude project2 as source directory.
However, when I want to create a new project with htdocs as a root folder, WebStorm sees the already created project.
Is it possible to create the project structure like I want?
Sure. But it involves additional manipulations.
The idea is simple -- store .idea folder (project settings .. and the clue/marker for IDE that this is a project) somewhere else:
Create new empty project somewhere else
Go to Settings/Preferences | Directories
Remove existing Content Root
Add new Content Root -- the folder(s) that you need.
You can A) add both folders as separate content roots (e.g. shared and project 1 as per your example) .. or B) add htdocs and then mark unwanted folders as excluded (so it's not indexed and not participating in code completion etc).
I suggest using A) option in general -- less files to work with for IDE (in B) -- even though the folders are excluded, they are still processed by IDE and can participate in certain activities).
Repeat the same for your 2nd project (for shared and project 2 folders)
https://youtrack.jetbrains.com/issue/WI-343 -- this ticket is for PhpStorm but describes the actual idea.
Alternatively:
Create project in project 1 folder (and not htdocs like you were planning originally)
Add additional Content Root -- add shared folder -- it will be listed as separate node in Project View.
Do the same for your 2nd project.
I would like to use Xcode to debug a C++ program step by step. The project can be build using make. How can I build it using Xcode 5?
Here are the steps
1) create a new project using the following
a) go to OS X other
b) Create an empty project
2) create a blank file (under OS X other again) and call it Makefile
3) create a new target (file -> new -> target - call it whatever you want)
go to OS X target and select external build system
4) If you want a particular PATH variable you can Add a new user define setting (under
editor -> add Build Setting -> Add user defined setting
5) This should enable your target to be the makefile
I have a Haskell project that aims to create some C++ bindings. I've written the C wrappers and compiled them into a stand-alone statically linked library.
I'd like to write the Haskell bindings to link statically to the C wrappers so that I don't have to distribute the C wrappers separately but I can't seem to get it working and would appreciate some help.
I specify the C library as an extra library but my cabal build step doesn't seem to add it to compile command.
I've created a small project to illustrate this (http://github.com/deech/CPlusPlusBindings).
It contains a small C++ class (https://github.com/deech/CPlusPlusBindings/tree/master/cpp-src), the C wrapper (https://github.com/deech/CPlusPlusBindings/tree/master/c-src), a working C test routine (https://github.com/deech/CPlusPlusBindings/tree/master/c-test) and the Haskell file (https://github.com/deech/CPlusPlusBindings/blob/master/src/BindingTest.chs).
The C library is added in Setup.hs not in the Cabal file because that's how I have it my real project which builds the C library using "make" through Cabal just before the build stepf. I have verified that at the build step the extraLibs part of BuildInfo contains the library name and extraLibDirs contains the right directory.
The output of my cabal build is:
creating dist/setup
./dist/setup/setup build --verbose=2
creating dist/build
creating dist/build/autogen
Building CPlusPlusBinding-0.1.0.0...
Preprocessing library CPlusPlusBinding-0.1.0.0...
Building library...
creating dist/build
/usr/local/bin/ghc --make -fbuilding-cabal-package -O -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -isrc -idist/build/autogen -Idist/build/autogen -Idist/build -I/home/deech/Old/Haskell/CPlusPlusBinding/c-src -I/home/deech/Old/Haskell/CPlusPlusBinding/cpp-includes -optP-include -optPdist/build/autogen/cabal_macros.h -package-name CPlusPlusBinding-0.1.0.0 -hide-all-packages -package-db dist/package.conf.inplace -package-id base-4.6.0.1-8aa5d403c45ea59dcd2c39f123e27d57 -XHaskell98 -XForeignFunctionInterface BindingTest
Linking...
/usr/bin/ar -r dist/build/libHSCPlusPlusBinding-0.1.0.0.a dist/build/BindingTest.o
/usr/bin/ar: creating dist/build/libHSCPlusPlusBinding-0.1.0.0.a
/usr/bin/ld -x --hash-size=31 --reduce-memory-overheads -r -o dist/build/HSCPlusPlusBinding-0.1.0.0.o dist/build/BindingTest.o
In-place registering CPlusPlusBinding-0.1.0.0...
/usr/local/bin/ghc-pkg update - --global --user --package-db=dist/package.conf.inplace
Unfortunately neither the compilation nor the linking step uses the C library. There are no other warnings or errors.
To solve this problem I had to:
re-link the Haskell library with the C bindings' object files and
use the ghc-options tag in my Cabal file to make sure they linked in the right order.
All the changes are in the test project (http://github.com/deech/CPlusPlusBindings).
Below the process of creating a new archive that includes both the C and Haskell objects is explained in detail and it is not simple. The complexity occurs because there is no way (as of Cabal 1.16.0.2) to hook into the linker part of the build process.
Setting the flags in the Cabal file is trivial so it is not described here.
Relinking The Haskell Library
Set the build type to custom by adding:
build-type: custom
to the cabal file.
Insert customized build logic by replacing the main method in Setup.hs with:
main = defaultMainWithHooks simpleUserHooks {
buildHook = myBuildHook,
...
}
This tells the build process that instead of going with the default build process defined in simpleUserHooks it should use the myBuildHook function which is defined below. Similarly the clean up process is overridden with the custom function myCleanHook.
Define the build hook. This build hook will run make on the command line to build the C++, and C portions and then use the C object files when creating linking the Haskell bindings.
We start off myBuildHook:
myBuildHook pkg_descr local_bld_info user_hooks bld_flags = do
by first running make with no arguments:
rawSystemExit normal "make" []
Then add the locations of the header files and library directories and the library itself to the PackageDescription record and update the LocalBuildInfo with the new package description:
let new_pkg_descr = (addLib . addLibDirs . addIncludeDirs $ pkg_descr)
new_local_bld_info = local_bld_info {localPkgDescr = new_pkg_descr}
Before the buildHook fired the configureHook stored the order of compilation in the compBuildOrder (component build order) key of the LocalBuildInfo record. We need to isolate the building of the library so we separate the library building and executable building parts of the build process.
The build order is just a list and we know the build component is a library if it's just a plain CLibName type constructor so we isolate those elements from the list and update the LocalBuildInfo record with only them:
let (libs, nonlibs) = partition
(\c -> case c of
CLibName -> True
_ -> False)
(compBuildOrder new_local_bld_info)
lib_lbi = new_local_bld_info {compBuildOrder = libs}
Now we run the default build hook with the updated records:
buildHook simpleUserHooks new_pkg_descr lib_lbi user_hooks bld_flags
Once it's done building an archive has been created but we have to re-create it to include the C objects generated by the make command in step 1. So we grab some settings and a list of the C object file paths:
let verbosity = fromFlag (buildVerbosity bld_flags)
info verbosity "Relinking archive ..."
let pref = buildDir local_bld_info
verbosity = fromFlag (buildVerbosity bld_flags)
cobjs <- getLibDirContents >>= return . map (\f -> combine clibdir f)
. filter (\f -> takeExtension f == ".o")
And then hand it off to withComponentsLBI which acts on each component of the build. In this case since we're only dealing with the library part there is only one component. Cabal provides getHaskellObjects for getting a list of the Haskell object files and createArLibArchive for creating an archive so we can re-run the linker:
withComponentsLBI pkg_descr local_bld_info $ \comp clbi ->
case comp of
(CLib lib) -> do
hobjs <- getHaskellObjects lib local_bld_info pref objExtension True
let staticObjectFiles = hobjs ++ cobjs
(arProg, _) <- requireProgram verbosity arProgram (withPrograms local_bld_info)
let pkgid = packageId pkg_descr
vanillaLibFilePath = pref </> mkLibName pkgid
Ar.createArLibArchive verbosity arProg vanillaLibFilePath staticObjectFiles
_ -> return ()
The default buildHook which was run in Step 4 created a temporary package database file named "package.conf.inplace" which holds the description of the library that was built so that executable can link against it without the library needing to be installed to the default system package file. Unfortunately every buildHook run blanks it out so we need to hold on to a temporary copy:
let distPref = fromFlag (buildDistPref bld_flags)
dbFile = distPref </> "package.conf.inplace"
(tempFilePath, tempFileHandle) <- openTempFile distPref "package.conf"
hClose tempFileHandle
copyFile dbFile tempFilePath
Now we store a path to that copy into the LocalBuildInfo structure along with the executable parts of the build process which were filtered out in Step 3.
let exe_lbi = new_local_bld_info {
withPackageDB = withPackageDB
new_local_bld_info ++
[SpecificPackageDB tempFilePath],
compBuildOrder = nonlibs
}
and store the path again in the extraTmpFiles part of the PackageDescription so it can be removed by the default clean up hook.
exe_pkg_descr = new_pkg_descr {extraTmpFiles = extraTmpFiles new_pkg_descr ++ [tempFilePath]}
Now we finally run the default buildHook again with the updated records (which now know about the new archive) on just the executable components:
buildHook simpleUserHooks exe_pkg_descr exe_lbi user_hooks bld_flags