| Export project as distribution to compile on another machine [message #166423] |
Wed, 22 March 2006 16:50  |
Eclipse User |
|
|
|
Hi -
Is there a way to export a CDT project (using managed build) so it can
be built on another machine?
The MBS creates makefiles, subdir.mk, et al, and I could gather them
all up and generate an export. Problem is that I must mirror the
directory tree in the export -- that is the "Debug" and "Release" part
of the tree. This includes any subdirs..... Certainly do-able but a bit
of a pain.
[ I'm developing on x86_64 machine, but need builds for i686 and am not
set up to cross-compile. If anyone wants to guide me through that
minefield, I'm all ears ;) ]
Thanks for any help,
Dan
|
|
|
|
| Re: Export project as distribution to compile on another machine [message #166489 is a reply to message #166455] |
Thu, 23 March 2006 19:33  |
| Eclipse User |
|
|
|
Feng wrote:
> Yes, I have a similar question to you. this is:
>
> Which command can I use to generate a executable file without IDE? so
> that I can debug my program in the remote site.
>
> Thanks.
>
> Feng
>
I've tried to answer my own question. Perhaps you (or others) can help
me enhance this scheme.
The MBS allows for customization of the make process via three
(optional) files which are included in the main makefile. These files
must be located in the project root folder, and are named
'makefile.init', 'makefile.defs' and 'makefile.targets'
My scheme is to define macros in 'makefile.defs' which include the
filenames which are to be exported. I'm not a 'make' expert, but I
managed with the following:
========== makefile.defs contents ============================
HDRS = $(shell find $(ROOT) -name '*.h')
INLS = $(shell find $(ROOT) -name '*.inl')
MKS = $(shell find $(ROOT) -name '*.mk')
MKFS = $(shell find $(ROOT) -name 'makefile*')
========== end makefile.defs ==================================
Each of the macros is a list of a certain type of file. My project uses
files with a ".inl" extension as inclusions, hence INLS. The last two
macros gather all the make-related files.
The source files are named in the macro CPP_SRCS, and I manipulate that
macro in 'makefile.targets' to get those files into the archive.
Now, the file 'makefile.targets' looks like this:
==============makefile.targets ===================================
src.tar:
-rm -rf src.tar
tar cvf $(ROOT)/src.tar -C $(ROOT)/ \
--exclude=*.o \
--exclude=*.d \
--exclude=*.so \
--exclude=*.a \
--exclude=CVS \
$(subst $(ROOT)/,./,$(CPP_SRCS)) \
$(subst $(ROOT)/,./,$(HDRS)) \
$(subst $(ROOT)/,./,$(INLS)) \
$(subst $(ROOT)/,./,$(MKS)) \
$(subst $(ROOT)/,./,$(MKFS))
============end makefile.targets ================================
The target 'src.tar' is built with straighforward tar command. The
exclusions work for me -- your mileage may vary. Some miscellaneous junk
gets picked up along the way.
I've made use of the fact that the makefiles reference the source
directories by navigating to $(ROOT). That means that the definitions in
the 'makefile.defs' files have a ../ prefix on them. Tar doesn't like
adding files with that kind of path, and it will strip off the "../",
which messes up the directory structure in the archive. Instead I came
up with the $(subst ...) stuff to replace the '../' with './'. The tar
command has a '-C $(ROOT)' in it, so it all works well together.
Usage:
Create the files 'makefile.defs' and 'makefile.targets' and add them to
your project root folder. Insert the contents from above. Modify where
necessary.
As far as I can tell, there is no way to add a new make target in the
IDE itself for a managed build project. Thus, to create the archive,
* cd to the Debug/ or Release/ folder (works the same from both). If
you've never built one or the other configuration, that folder may not
exist.
* type
make src.tar
The resulting file 'src.tar' should be in the project's root folder (one
level above where you ran the command from).
Problems:
My project uses env variables defined in
Windows>Preferences>C/C++>Managed Build>User Variables.
That's so when I do development on different machines, and I have
libraries and headers in different locations it all still works. Well,
outside of the IDE you don't have access to those env variables. This is
easy to workaround (I defined the same env variables in the
makefile.defs file on the target machine. Be careful! If you do this on
your development machine you might get unexpected results -- like your
settings in Windows>preferences....>User Variables being overridden by
these settings in makefile.defs. I'll likely switch to using
makefile.defs for all these macros, then its up to me/someone else to
modify those macros to point to the proper directories on the target
machine.
The archive file doesn't create the top-level project directory; it
creates all its contents and subdirs. There's probably a clever way to
pull that off, but I didn't have the time this morning.
I've left off other types of source files, though they can be easily
added (just follow the syntax of the 'subst' above.
I hope this works out for you. If anyone uses this scheme and finds a
way to improve it, please reply here so others can share the trick.
Dan
|
|
|
Powered by
FUDForum. Page generated in 0.02686 seconds
Home