Re: Best practices for cross-project development (and version control too?)
Re: Best practices for cross-project development (and version control too?)
- Subject: Re: Best practices for cross-project development (and version control too?)
- From: Greg Guerin <email@hidden>
- Date: Tue, 1 Jul 2008 09:05:13 -0700
Lukhnos D. Liu wrote:
Oh, it's problematic when the project files are to be shared
outside of the house, for example when we share one framework
project and one main app project with a client of ours, then it
becomes an intrusive thing to ask them to set their Xcode that
way... all the more so when the comparison with Visual Studio
(where the solution-project relationship, although having their own
problems, is quite a good way of offering what we have in mind).
Treat your projects, or the individual targets, as individual products.
There is nothing wrong with having in-house products that are only
"released" as pre-built modules to in-house developers. In the days
when I worked at a big corporation, this was quite common practice.
For example, the C runtime support libs, the C stdio lib and headers,
the C compiler itself. These were obviously shipped to customers,
but there was an internal cycle, too, and sometimes custom builds.
Also, there were internal-use libs for certain devices, programs that
were only used for testing hardware in manufacturing that never went
outside, etc.
I have tried that. My problem is that script doesn't seem to scale
well (perhaps there are better ways to automate it I'm not aware
of) as project grows, there is always some extra check to do, some
extra work...
Use the install-location of the Release configuration. This implies
you will be treating the target as a product to be installed in a
certain location.
For in-house distribution, you can do whatever suits your purpose.
An Installer is one option. A script that copies the latest version
of the built product from the repository is another. It depends on
how you decide to do your internal distribution.
If you think of this as an actual product, with a product
distribution problem, then the choices you need to make will be a lot
clearer. For example, you'll need some version-numbering, some
public API contracts, possibly some way to check for updates (e.g.
Software Update-like), and some other things that go into maintaining
a software product (e.g. bundling decisions).
Not every problem can, or should, be solved with version control.
Sometimes the answer is product distribution control.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden