[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Using nmake with managed builds
|
Leo,
this proposal looks fine. It is a pity
though that this cannot be done statically.
A few things are not totally clear to
me, so I wanted to double check whether I understood everything correctly:
(1) Does invocationType have only two
values (line in UI, for build)?
(1a) If it has a 3rd (for build, but
externalise options to file) - how does MBS decide when to move the command
line contents to a file?
(1b) If it has the two, this would mean
that the decision as to whether to externalise, has to be made in generateCommandLineInfo(...)
(2) Do you think in practice that getTemporaryBuildFiles()
and getTemporaryBuildFilesToDelete() will return different values? After
all the commandline info generator does not know when these files become
invalid. In some way the temporary files are invalidated when the "parent"
makefile is.
In terms of usage model - assuming 1b
we would get the following steps. Please correct me if wrong:
A) generateCommandLineInfo is called
and decides whether to externalise
B) If yes, choose a temporary filename
B.1) Externalise some options to temporary
file
B.2) Change command line such that temporary
file is referred to
B.3) Cache temporary file name (such
that it can be used by the delete commands)
C) If no AND B was not true before,
generate the command line
D) If no AND B was true, then generate
the command line AND invalidate the cache. ASIDE START: And maybe add to
a 2nd cache that contains temporary files that are scheduled for demolition?
But how would I be able to tell that the file got deleted? When getTemporaryBuildFilesToDelete()
was called? ASIDE END
This logic sounds a bit complex and
maybe it can be handled better by MBS. MBS can find out the difference
between the list of temporary files before and after the call to generateCommandLineInfo
- it mereley needs to call getTemporaryBuildFiles() twice, compare the
lists, then delete any "old" temporary files.
Also all the caching is where it becomes
interesting. The caching requires that the object implementing IManagedCommandLineGenerator2
lives as long as the build configuration, otherwise caching cannot be performed
unless some id passed into getTemporaryBuildFiles() to pick up cached values
from a global store. So I guess some statement about the life-time of these
objects is needed.
Also a utility function which creates
unique temporary file names would be good (some Java API may exist already
- I did not check).
Best Regards
-- Lars
"Treggiari, Leo"
<leo.treggiari@xxxxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx
04/10/2005 15:18
|
Please respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx> |
|
|
To
| "CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| RE: [cdt-dev] Using nmake with managed
builds |
|
I have made a proposal for how to allow a tool integrator
to solve the
command line length problem in bugzilla 72965. If you are interested,
please take a look and comment.
Leo
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Alex Chapiro
Sent: Monday, October 03, 2005 8:07 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Using nmake with managed builds
Sounds strange. I tried nmake and got 32K length limit which is quite
enough for any reasonable project. I used VC++6.0 for testing.
vladchuk wrote:
>Alex Chapiro wrote:
>
>
>
>>I'm using cygwin make and WinXP for testing, i.e. exactly the case
we
>>discussed. It successfully accepts command line longer than 16K.
I
>>guess the limit is 32K (I just was lazy to test it), which is,
I
>>suppose, much more than any reasonable requirement. What I'm saying,
>>there is no problem of command line length limitation with GNU
make on
>>
>>
>
>
>
>>Windows environment. It still maybe exists for nmake.
>>
>>Recoskie, Chris wrote:
>>
>>
>>
>>>Yes, but of course YMMV depending on what make utility and
OS you are
>>>using.
>>>
>>>You might find this tidbit I culled from the web interesting
>>>
>>>(http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx)
>>>
>>>What is the command line length limit?
>>>It depends on whom you ask.
>>>The maximum command line length for the CreateProcess function
is
>>>
>>>
>32767
>
>
>>>characters. This limitation comes from the UNICODE_STRING structure.
>>>CreateProcess is the core function for creating processes,
so if you
>>>
>>>
>are
>
>
>>>talking directly to Win32, then that's the only limit you have
to
>>>
>>>
>worry
>
>
>>>about. But if you are reaching CreateProcess by some other
means,
>>>
>>>
>then
>
>
>>>the path you travel through may have other limits.
>>>If you are using the CMD.EXE command processor, then you are
also
>>>subject to the 8192 character command line length limit imposed
by
>>>CMD.EXE.
>>>If you are using the ShellExecute/Ex function, then you become
>>>
>>>
>subject
>
>
>>>to the INTERNET_MAX_URL_LENGTH (around 2048) command line length
>>>
>>>
>limit
>
>
>>>imposed by the ShellExecute/Ex functions. (If you are running
on
>>>
>>>
>Windows
>
>
>>>95, then the limit is only MAX_PATH.)
>>>While I'm here, I may as well mention another limit: The maximum
size
>>>
>>>
>of
>
>
>>>your environment is 32767 characters. The size of the environment
>>>includes the all the variable names plus all the values.
>>>Okay, but what if you want to pass more than 32767 characters
of
>>>information to a process? You'll have to find something other
than
>>>
>>>
>the
>
>
>>>command line. We'll discuss some options tomorrow.
>>>
>>>___________________________________________
>>>
>>>Chris Recoskie
>>>Software Designer
>>>Texas Instruments, Toronto
>>>http://eclipse.org/cdt
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: cdt-dev-bounces@xxxxxxxxxxx
>>>>
>>>>
>[mailto:cdt-dev-bounces@xxxxxxxxxxx]
>
>
>>>>
>>>>
>>>>
>>>On
>>>
>>>
>>>
>>>
>>>>Behalf Of Alex Chapiro
>>>>Sent: Friday, September 30, 2005 2:30 PM
>>>>To: CDT General developers list.
>>>>Subject: Re: [cdt-dev] Using nmake with managed builds
>>>>
>>>>I included the following command into make file (WinXP)
:
>>>>
>>>>gcc -c -D$(TTTTT) myFile.c
>>>>
>>>>where TTTTT contained 7000 characters and launched
it. File
>>>>
>>>>
>myFile.c
>
>
>>>>was successfully compiled. Are you talking about this command
line?
>>>>
>>>>Recoskie, Chris wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Like Mikhail says, the make utility (whether it's GNU
make, nmake,
>>>>>
>>>>>
>>>>>
>>>any
>>>
>>>
>>>
>>>
>>>>>make-alike will do) issues the commands via the OS
shell. The OS
>>>>>
>>>>>
>(in
>
>
>>>>>this case, windows) will generally have a limitation
on the length
>>>>>
>>>>>
>of
>
>
>>>>>
>>>>>
>>>>>
>>>a
>>>
>>>
>>>
>>>
>>>>>command.
>>>>>
>>>>>Make and nmake themselves don't limit the length to
my knowledge,
>>>>>
>>>>>
>but
>
>
>>>>>when they try to invoke the command via the shell,
it fails due to
>>>>>
>>>>>
>>>>>
>>>the
>>>
>>>
>>>
>>>
>>>>>length issue.
>>>>>
>>>>>___________________________________________
>>>>>
>>>>>Chris Recoskie
>>>>>Software Designer
>>>>>Texas Instruments, Toronto
>>>>>http://eclipse.org/cdt
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: cdt-dev-bounces@xxxxxxxxxxx
>>>>>>
>>>>>>
>>>>>>
>>>[mailto:cdt-dev-bounces@xxxxxxxxxxx]
>>>
>>>
>>>
>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>On
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Behalf Of Alex Chapiro
>>>>>>Sent: Friday, September 30, 2005 1:52 PM
>>>>>>To: CDT General developers list.
>>>>>>Subject: Re: [cdt-dev] Using nmake with managed
builds
>>>>>>
>>>>>>If you are talking about make command line, you
can for example
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>instead
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>of generating long command line , create temporary
make file, fill
>>>>>>
>>>>>>
>>>>>>
>>>it
>>>
>>>
>>>
>>>
>>>>>>with your command line arguments and add include
Makefile at the
>>>>>>
>>>>>>
>end
>
>
>>>>>>
>>>>>>
>>>>>>
>>>>>of
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>it, then launch make --file=<tempFile>, then
remove <tempFile>. If
>>>>>>
>>>>>>
>>>>>>
>>>you
>>>
>>>
>>>
>>>
>>>>>>are taking about length limitation of commands
in make file, I
>>>>>>
>>>>>>
>don't
>
>
>>>>>>know about it. Does it really exist?
>>>>>>
>>>>>>Sennikovsky, Mikhail wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Hi,
>>>>>>>
>>>>>>>Cygwin make has also command length limitation,
that actually has
>>>>>>>
>>>>>>>
>>>>>>>
>>>to
>>>
>>>
>>>
>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>do
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>with the command length limitation on windows
in general.
>>>>>>>Please see the bugzilla# 72965 related to this.
>>>>>>>
>>>>>>>Thanks,
>>>>>>>Mikhail
>>>>>>>
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: cdt-dev-bounces@xxxxxxxxxxx
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>[mailto:cdt-dev-bounces@xxxxxxxxxxx]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>On Behalf Of vladchuk@xxxxxxxxxxx
>>>>>>>Sent: Friday, September 30, 2005 9:32 PM
>>>>>>>To: Cdt-dev@xxxxxxxxxxx
>>>>>>>Subject: [cdt-dev] Using nmake with managed
builds
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Apparently, nmake has a makefile command
length limitation (is
>>>>>>>
>>>>>>>
>it
>
>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>1024
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>chars?) so it is impossible to use it
with anything but trivial
>>>>>>>projects.
>>>>>>>Does anybody know how toget around this
problem?
>>>>>>>
>>>>>>>Thanks,
>>>>>>>vladchuk
>>>>>>>
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>cdt-dev mailing list
>>>>>>>cdt-dev@xxxxxxxxxxx
>>>>>>>https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>>>>>>_______________________________________________
>>>>>>>cdt-dev mailing list
>>>>>>>cdt-dev@xxxxxxxxxxx
>>>>>>>https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>_______________________________________________
>>>>>>cdt-dev mailing list
>>>>>>cdt-dev@xxxxxxxxxxx
>>>>>>https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>_______________________________________________
>>>>>cdt-dev mailing list
>>>>>cdt-dev@xxxxxxxxxxx
>>>>>https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>_______________________________________________
>>>>cdt-dev mailing list
>>>>cdt-dev@xxxxxxxxxxx
>>>>https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>>>
>>>>
>>>>
>>>_______________________________________________
>>>cdt-dev mailing list
>>>cdt-dev@xxxxxxxxxxx
>>>https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>>
>>>
>>>
>>>
>>>
>>_______________________________________________
>>cdt-dev mailing list
>>cdt-dev@xxxxxxxxxxx
>>https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
>>
>>
>Well, after reading all the responses and doing some investigation
of
my
>
>own it indeed appears that 8K (CMD shell limit) all we can get when
>using nmake.
>The solution is then (also suggested by Microsoft) to keep the paths
as
>short as possible. I don't suppose it is possible to use any other
shell
>
>with nmake.
>
>I wonder how MS gets around their own limitations when using nmake
on
>large projects?
>
>vladchuk
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
**********************************************************************
Symbian Software Ltd is a company registered in England and Wales with
registered number 4190020 and registered office at 2-6 Boundary Row,
Southwark, London, SE1 8HP, UK. This message is intended only for use by
the named addressee and may contain privileged and/or confidential
information. If you are not the named addressee you should not disseminate,
copy or take any action in reliance on it. If you have received this
message in error please notify postmaster@xxxxxxxxxxx and delete the
message and any attachments accompanying it immediately. Neither Symbian
nor any of its subsidiaries accepts liability for any corruption,
interception, amendment, tampering or viruses occurring to this message in
transit or for any message sent by its employees which is not in compliance
with Symbian corporate policy.
**********************************************************************
